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This  report  is  the  result  of  my  efforts  to  design, 


implement,  and  test  an  interaotive  flight  simulation  with 
graphics  interface  for  a  bombing  mission  program  used  by 
analysts  in  the  Avionics  Laboratory,  Air  Force  Fright 
Aeronautical  Laboratories.  The  document  is  written  for 
readers  with  some  knowledge  of  computer  programming  in  high 
level  languages  and  interactive  computer  graphics.  The 
design  and  analysis  is  documented  using  the  SADT  approach. 
The  software  is  written  in  FORTRAN,  and  the  graphics  are 
accomplished  using  PLOT-10  software  on  a  TEKTRONIX  i<0l6 
term ina  1  . 
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iSn  inter  rctive  flight  eimuletion  vith  comrnter 
graphics  interface  was  designed  using  top-down  structured 
analysis  techniques.  The  project  converts  a  passive 
bombing  mission  simulation  used  in  the  Avionics 
Laboratory,  Air  Force  Wright  Aeronautical  Laboratories  at 
Wright-Patterson  AFP,  into  an  interactive,  real-time, 
man-in-loop  simulation.  The  design  was  documented  using 
SofTech's  Structured  Analysis  and  Design  Technique  (SADT) 
then  coded  in  FORTRAN.  The  graphics  were  implemented  using 
TEKTRONIX  PLOT-10  software  and  the  system  operates  on  a 
VAX-11/780  computer  coupled  through  a  TEKTRONIX  0  1  f 


term ina 1  . 


AN  INTERACTIVE  BOMBING  MISSION  SIMULATION 


WITH  COMPUTER  GRAPHICS  INTERFACE 


I  Introduction 


A  nation's  success  or  failure  in  a  conventional  war 
is  ultimately  dependent  on  that  nation  attaining  and 
maintaining  air  superiority.  To  attain  air  superiority 
requires  the  capability  to  effectively  penetrate  the  enemy 
defensive  system  with  tactical  and  strategic  weapons. 
Manned  bombers  comprise  a  large  percentage  of  both  tactical 
and  strategic  weapons.  Whether  a  bomber  will  effectively 


penetrate  an  enemy's 

defensive 

network 

and  destroy 

its 

planned  targets  is 

determined 

by  a 

combinat ion 

and 

interaction  of  several  factors. 

The 

first  ,  and 

most 

critical  factor  is  the  type,  number,  and  planned  use  of 
electronic  countermeasure  equipment.  Next  are  the 
aircraft  parameters  of  airspeed,  altitude,  and  approach 
heading  relative  to  the  defensive  system.  Since 

intelligence  data  is  seldom  perfectly  accurate,  and  what 
was  true  of  the  enemy  system  yesterday  may  have  been 
changed  by  today  anyway,  another  major  consideration  is  the 
pilot's  skill,  intuition  and  reaction  to  the  hostile 
environment  as  the  mission  develops.  Uncontrollable 
elements  make  'p  a  fc  -th  category.  Weather,  such  as 


thunderstorms  or  leavy  precipitation,  is  notorious  for 
producing  unusual  returns  on  radar.  These  effects  may  also 


hide  radar  returns  which  normally  would  have  been  observed. 
Chance  also  plays  an  untold  role.  A  jammer  might  indicate 
on  in  the  cockpit,  but  actually  not  produce  a  signal,  or  an 
enemy  SAM  system  may  not  fire  due  to  some  malfunction. 

Clearly,  with  this  many  factors  to  consider,  and  with 
the  innumerable  potential  combinations  and  interactions 
among  these  factors,  it  is  a  complicated  problem  to 
determine  the  overall  effect  of  a  change  in  one,  or  any 
combination  of  the  input  parameters.  It  obviously  is  not 
cost  effective,  and  in  many  cases  not  even  possible  to  do 
inflight  testing  of  each  parameter  adjustment  in  order  to 
optimize  the  mission  profile.  The  Analysis  Group  attacked 
this  problem  by  using  several  different  simulation  programs 
to  analyze  the  effectiveness  of  various  electronic 
countermeasure  systems  in  use  by  the  U.  S.  Air  Force. 

The  mission  simulation  programs,  called  the  Avionics 
Air  Defense  Evaluation  Model  (AADEM),  currently  used  by  the 
Anal ys is  Group  are  written  mostly  in  FORTRAN  IV,  with  some 
routines  written  in  updated  versions  of  FORTRAN.  AADEM  is 
run  on  a  Digital  Equipment  Corporation  VAX  11/780  Computer 
System.  The  programs  reouire  that  the  aircraft  flight  path 
be  defined  completely  before  program  execution.  This 
requires  that  all  aircraft  events  such  as  heading, 
airspeed,  or  altitude  changes,  electronic  countermea sure 
(ECM)  configuration  changes,  and  target  selection/weapon 
firing  must  be  predetermined  and  formatted  as  input  to  the 
various  simulation  programs.  An  error  in  this  input  data 


results  in  an  invalid  simulation  run,  which  may  reouire 
several  days  to  locate  and  correct  the  error,  reffeneratc 
the  input  deck,  and  rerun.  /!lso,  in  order  to  make  orly  one 
small  change  in  the  mission  profile  recuires  that  the 
entire  input  deck  be  reenterred  with  the  modification. 


Because  of  the  above  limitations,  the  Avionics 
Laboratory  requires  a  flight  simulation  of  an  aircraft 
penetrating  an  enemy  deployment  of  surface-to-air  missiles 
(SAM)  and  anti-aircraft  artillery  (AAA)  with  the  capability 
to  simulate  interactive  "pilot"  actions.  Ideally,  the 
program  should  process  an  initial  predefined  flight  path 
using  the  same  routines  currently  in  use  by  the  Analysis 
Group.  In  addition,  it  should  give  an  interactive  "pilot" 
the  information  normally  available  in  an  aircraft  cockpit, 
in  a  graphical  format,  and  allow  for  modification  to  the 
mission  profile  in  as  close  to  actual  time  as  possible. 
[Fef  1] 

With  this  type  of  simulation  program,  the  analysts 
will  be  able  to  produce  a  test  environment  which  parallels 
an  actual  flight  much  more  closely  than  the  passive 
simulations  currently  in  use.  Also,  any  errors  in  the 
predefined  flight  path  can  be  corrected  by  the  "pilot" 
during  simulation  execution,  thereby  reducing  the  amount  of 
time  needed  to  obtain  a  valid  test  run. 


The  approach  was  eoverned  by  two  conflicting  ideals: 
Ke  wanted  to  implement  and  test  a  model  rather  than  merely 
design  one.  However,  to  build  a  complete  bombing  mission 
simulation  is  too  large  a  project  for  a  thesis  effort.  The 
compromise  was  to  be  satisfied  with  only  partial 
development  of  some  aspects  of  the  simulation.  The 
particular  details  of  these  compromises  follow. 

Using  software  engineering  principles  and  technioues, 
the  simulation  was  structured  into  modules,  with  each 
detail  in  its  own  module.  In  this  way  the  modules  can  be 
enhanced  later  to  whatever  degree  is  desired.  In  addition 
to  the  modeling  of  a  bombing  mission,  this  project  uses 
TEKTRONIX  PLOT-10  [Ref  2]  graphics  to  interface  with  the 
"pilot"  and  thereby  furnish  the  information  normally 
available  in  an  aircraft  cockpit.  PLOT-10  rather  than  Core 
Standard  [Ref  3]  graphics  were  used  not  by  choice,  but 
because  no  Core  Standard  package  was  available  on  the 
Avionics  Laboratory  computer  when  this  project  was  begun. 
Modular  design  with  a  clean  graphics  interface  will  make 
translation  to  other  graphics  routines  straight  forward. 

As  partial  justification  for  my  approach  to  this 

project  I  offer  the  folowing  by  Robert  Shannon,  author  of 

many  books  and  articles  dealing  with  computer  modeling. 

The  approach  to  the  successful  building 
of  models  appears  to  proceed  on  the  basis 
of  elaboration  and  enrichment.  One 
begins  with  a  very  simple  model  and 
attempts  to  move  in  an  evolutionary 
fashion  toward  a  more  elaborate  model 


that  reflects  the  complex  situation  more 
clearly.  Analogy  or  association  with 
previously  we  1 1 -d e v e 1 o p e d  structures 
appears  to  play  an  important  role  in 
determining  the  starting  point  for  this 
process  of  elaboration  and  enrichment. 

The  process  of  elaboration  and  enrichment 
involves  a  constant  interaction  and 
feedback  process  between  the  real  world 
situation  and  the  model  .  There  is  a 
constant  interplay  between  the 
modification  of  the  model  and  a 
confrontation  with  the  data  generated. 

As  each  version  of  the  model  is  tested 
and  attempts  to  validate  it  are  made,  a 
new  version  is  produced  that  leads  to  a 
retesting  and  revalidation.  As  long  as 
the  model  is  computationally  tractable, 
the  analyst  may  seek  further  enrichment 
or  complication  of  the  assumptions.  V'hen 
it  becomes  intractable  or  cannot  be 
solved,  he  resorts  to  simplification  and 
further  abstraction. 

[Ref  14:  19,20] 

Some  of  the  design  work  of  the  interactive  graphics 
for  this  project  was  done  by  Capt .  Randy  Krause  as  his  AFIT 
thesis  in  1978.  [Ref  5]  Since  Capt.  Krause's  design  was  to 
be  implemented  as  a  time-shared  Job  on  the  ASD  CYBER 
Computer  using  a  CDC  CYBER  GRAPHICS  terminal,  several 
modifications  were  made  to  his  design.  His  work  did  serve 
as  background  for  this  project,  and  as  a  reference  against 
which  to  cross  check  ideas. 

In  the  next  chapter,  the  fundamentals  of  simulation 
and  modeling,  which  served  as  the  cornerstone  of  my 
project,  are  briefly  discussed.  This  chapter  can  be 
skipped  with  no  loss  of  continuity. 


I I  Simulation  and  Modeling 


The  fundamental  concept  of  systems  analysis  is  that 
changing  one  aspect  of  a  system  might  very  /iell  change,  or 
create  the  need  for  changes  in  other  related,  or  seemingly 
unrelated  parts  of  that  system.  As  man-made  systems  become 
increasingly  large,  and  the  interrelationships  of  the 
subparts  become  increasingly  complex,  engineers  and 
planners  have  a  more  and  more  difficult  time  predicting  and 
controlling  the  outcomes  of  various  inputs.  One  very 
useful  tool  in  helping  to  observe  the  outcome  of  various 
inputs,  and  thereby  improve  the  understanding  of  a 
complicated  system,  is  computer  simulation. 

Simulation  is  the  process  of  designing  a  model  of  a 
real  system  and  conducting  experiments  with  this  model 
either  to  better  understand  the  behavior  of  the  system  or 
to  evaluate  various  strategies  (within  the  limits  imposed 
by  a  set  of  criteria)  for  the  operation  of  the  system.  To 
simulate,  then,  is  to  both  construct  a  model  which 
( ho pe fully)  accurately  describes  the  interrelationships  of 


all  parts 

of  a 

sy St em  , 

and 

then 

to 

use 

this  model 

to 

predict  th 

e  effects  that 

will 

be 

prod  uced 

by  changes 

in 

either  the 

system 

itself , 

or 

some 

of 

the 

methods  of 

its 

operation . 

Three  methods  of  studying  a  bombing  mission  are 
typically  employed:  digital  models,  simulators,  and 


6 


flight  tests.  A  digital  model  is  another  name  for  a 
computer  model  //hieh  usually  has  all  parameters  and  events 
established  prior  to  beginning  the  simulation.  A  simulator 
is  a  computer  model  /^hich  has  a  man-in-loop  facility  to 
incorporate  dynamic  inputs  and  changes  as  the  simulation 
progresses.  It  uses  hard/^are  and  realistic  displays  of 
actual  equipment  to  simulate  the  real  <Jorld  system.  Flight 
tests  involve  using  real  aircraft  //ith  simulated  threats 
and  defense  systems  with  associated  operations  performed  in 
a  controlled  environment.  In  choosing  which  method  to 
employ  the  analyst  must  evaluate  several  advantages  and 
limitations  . 

It’s  easy  to  see  that  digital  models  and  simulators 
offer  much  stricter  control  than  can  be  achieved  with 
flight  testing  and  it  is  much  easier  to  make  configuration 
changes.  Computer  simulation  is  also  considerably  less 
costly  and  requires  less  instrumentation  to  collect  output 
data.  Simulators  are  an  obvious  improvement  over  purely 
digital  models  since  the  human  interactions  with  realistic 
simulations  of  ECM  hardware  and  radar  equipment  enhance 
realism.  Put  they  still  are  limited  compared  to  flight 
tests  since  there  are  restrictions  on  the  number  of 
aircraft,  ECM  capabilities,  and  real  world  interactions 
which  can  be  simulated  without  dedicating  more  computer 
power  than  is  typically  available.  However,  these  limits 
are  rapidly  melting  away  with  advances  in  hardware. 

Flight  tests  can  do  anything  that  a  simulation  can. 
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if  the  analyst  vill  support,  the  overhead  costs  required  to 
establish  the  mission  profile.  In  addition,  they  can 
evaluate  equipment,  tactics,  and  operational  readiness. 
The  advantages  include  the  capability  to  use  multiple 
aircraft,  multiple  penetration  aids,  incorporate  more  real 
/rforld  in t er ac t i on  5  ,  and  thus  a  higher  degree  of  realism. 
Its  limitations  include  tremendous  costs  in  personnel  and 
instrumentation  to  collect  data,  limited  control,  fixed 
geography  for  the  test  flight,  and  restrictions  on  the 
ability  to  alter  the  defensive  structure.  Figure  1  below 
summarizes  the  three  methods  of  collecting  system  data 
according  to  several  measures  of  value. 
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FIGURE  1 

A  Comparsion  of  Simulations  with  Real  V.'orld 
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An  additional  advantage  of  simulation  is  that  it 
forces  the  model  builder  to  thoroughly  analyze  the  system 
and  study  the  various  interrelations  of  the  parts. 
Manipulating  the  various  subsystems  /<hile  building  the 
model  often  educates  the  builder  and  gives  him  or  her  more 
and  different  ideas  of  potential  changes  to  the  inputs  to 
improve  system  performance.  There  is  one  more  disadvantage 
to  simulation  rfhich  is  often  addressed.  As  stated  above, 
the  outputs  of  a  simulation  merely  result  from  a 
combination  of  the  inputs,  and  the  model  builder's 
assumptions  about  the  real  /jorld  .  The  outputs  are  al  ways 
imprecise,  but  it  is  difficult,  if  not  impossible  to 
determine  how  imprecise.  Since  the  outputs  are  usually 
numbers,  the  number  of  digits  printed  may  bear  little 
relation  to  the  accuracy  of  the  model's  assumptions.  If 
the  printing  of  the  output  is  not  carefully  formatted,  the 
results  can  be  very  misleading  to  analysts  unfamiliar  with 
the  capabilities  of  the  model. 

Clearly,  there  are  many  potential  advantages  and 
disadvantages  in  using  a  computer  simulation  rather  than 
direct  ex  per im en t a t i on  with  the  real  system.  Obviously, 
direct  experimentation  precludes  the  problem  of  building  a 
model  which  is  not  an  accurate  representation  of  the  real 
world,  and  from  it  deriving  false  predictions  of  the 
future.  However,  sometimes,  as  in  the  case  of  a  bombing 
mission,  direct  ex  per imentat ion  is  not  possible.  In  fact. 
Shannon  gives  six  conditions  under  which  an  analyst  should 


consider  the  use  of  simulation.  Of  the  six,  the  following 
three  fit  this  problem. 

1)  A  complete  mathematical  formulation 

of  the  problem  does  not  exist  or 
a  n  a  1  y  t  i  e  a  1  methods  of  s  o  1  v  i  n  j".  the 
mathematical  model  have  not  yet  been 
developed.  Many  /jaiting  line 

(queueing)  models  are  in  this 
category. 

2)  It  is  desired  to  observe  a  simulated 
history  of  the  process  over  a  period 
of  time  in  addition  to  estimating 
certain  parameters. 

j)  Simulation  may  be  required  for 
systems  or  processes  rfith  long  time 
frames.  Simulation  affords  complete 
control  over  time,  since  a  phenomenon 
may  be  speeded  up  or  slo^red  do^n  at 
will.  Analysis  of  urban  decay 

problems  is  in  this  category. 

[Ref  1 1  ] 

The  idea  of  a  simulation  to  solve  this  problem  is 
initially  appealing,  and  appears  appropriate  in  that  it 
fits  half  of  Shannon's  criteria  as  stated  above,  but  to 

keep  it  in  perspective  remember  that  a  simulation  never 

solves  a  problem.  A  simulation  is  run  with  a  given  set  of 
inputs,  and  from  the  inputs,  and  the  criteria  of  the  model, 
it  generates  outputs.  It  is  Incapable  of  reaching  a 

conclusion  on  its  own,  but  serves  only  as  a  tool  to  help 

the  analyst  understand  the  behavior  of  the  system  and  the 
affects  of  various  changes  of  inputs. 

Now,  if  we  agree  that  a  computer  model  is  a  valid 

tool  with  which  to  attack  a  problem,  how  do  we  go  about 
building  one?  Clearly  we  must  analyze  the  problem  and  try 

to  extract  the  essential  features  without  leaving,  out  any 

critical  details.  Next,  we  structure  our  set  of  essential 
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features  into  an  approx imation  (possibly  very  crude)  of  the 
real  system.  We  then  enrich  and  elaborate  this 
approximation  until  a  useful  predictor  results. 

Several  sources  list  the  following  set  of  guidelines 
to  help  an  analyst  design  a  model. 


1)  Factor  the  system  into  a  collection 
of  smaller  s ub s y s t em s  . 

2)  Clearly  state  the  objectives  of  the 
s im ul a t i on  . 

j)  Seek  analogies  to  otlier  models  or 
systems . 

4)  Consider  specific  instances  of  the 
problem. 

5)  Establish  some  symbols. 

6)  V/rite  down  the  obvious. 

7)  If  a  usable  model  results,  enrich  it. 

If  not,  simplify. 

[Ref  7  1 

Simplification  is  the  key  which  opens  any  system  to  the 
model  builder.  For  example,  make  variables  into  constants, 
restrict  the  boundaries  of  the  system  and  use  linear 
approximations.  These  approximations  can  be  enriched  and 
the  model  improved  after  the  first  model  is  operating.  The 
bottom  line  is  don't  get  bogged  down  with  details  too  early 
in  the  project.  Clearly,  the  standard  approach  to  model 
building  is  not  to  try  one  al 1-encompassing  simulation  on 
the  first  attempt,  but  rather  to  begin  with  a  very  basic 
and  straight  forward  model,  and  then  enrich  it  as  the 
system  becomes  increasingly  familiar  to  the  builder  and 
user.  Since  model  building  is  inherently  an  evolutionary 
process,  a  computer  model,  even  more  than  other  computer 
software  must  be  written  modularly,  with  flexibility  and 
probability  of  change  foremost  in  the  programmer's  mind. 


Considering  that  models,  by  nature,  evolve,  a  "good" 
model  is: 

1)  Simple  for  the  user,  to  understand,  control, 
and  communicate  A(i t h 

2)  Robust,  In  that  it  does  not  give  absurd 
an s  wer  s 

Complete  on  important  issues 
4)  Adaptive,  and  modular  to  allow  for  enrichment 
b '■  E  V  ol  ut  I  onar  y ,  in  that  it  should  start  simply 
and  become  more  complex,  in  conjunction  with 
the  user 

It  is  not  my  purpose  in  this  report  to  thoroughly 
discuss  all  factors  which  need  to  be  considered  while 
designing  and  building  a  computer  model.  I  merely  wanted 
to  touch  on  what  I  consider  the  most  important 
considerations,  and  to  somewhat  justify  m:  approach  to  this 
interactive  simulation  effort.  For  those  readers 

interested  in  more  information  on  computer  simulation  and 
modeling,  I  highly  recommend  references  4,  6,  7,  and  8  from 
my  bibliography. 

In  closing  this  chapter,  I  present  this  "summary" 

about  model  building: 

There  is  no  hard  and  fast  rule  about  how 
the  problem  is  originally  formatted, 
i.e.,  how  one  looks  at  it  in  the  first 
place.  There  are  no  magic  formulas  for 
deciding  what  should  be  included  in  the 
model  in  the  form  of  variables  and 
parameters,  descriptive  relationships  and 
constraints,  and  criterion  for  judgement 
of  effectiveness.  Remember  that  nobody 
solves  the  problem;  rather,  everybody 
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solves  the  model  that  he  has  constructed 
of  the  problem.  This  concept  helps  to 
keep  the  model  and  the  art  of  modeling  in 
the  pro  per  perspective. 

[Ref  i4:21] 

V/ith  these  ^ords  of  guidance,  I  am  ready  to  establish  the 
project  specifications. 


1  j 


Development  of  this  system,  like  any  software 
enginering  effort,  must  begin  by  laying  down  a  conceptual 
framework  for  the  project.  Normally,  the  final  user  of  a 
software  package  will  designate  in  considerable  detail  the 
requirements  and  capabilities  for  the  proposed  system. 
However,  for  a  thesis  effort,  it  is  more  common  for  the 
project  sponsor  to  state  desires  in  more  general  terms,  and 
leave  the  requirements  definition  and  project  scoping  to 
the  graduate  student  and  the  thesis  advisor.  This  chapter 
will  document  the  desired  capabilities  for  the  proposed 
system . 

The  Analysis  Group  wanted  a  graphical  interface 
between  the  "pilot"  and  computer  built  using  a  TEKTRONIX 
^016  terminal.  This  terminal  offers  two  modes  of 
interaction:  direct  keyboard  inputs  and  crosshair 
position/selection.  Pilot  Inputs  would  be  a  combination  of 
menu  picks  using  the  crosshair  capability  of  the  ^016 
terminal  and  keyboard  inputs  to  further  define  pilot 
actions  when  required.  Output  would  be  a  graphical 
representation  of  a  Radar  Warning  Display,  a  graphical 
representation  of  what  the  pilot  could  actually  see  through 
the  aircraft  windows,  and  a  block  containing  cockpit 
instrument  values  and  equipment  status.  In  particular,  the 
following  objectives  were  established. 


In  order  to  eimulate  an  aircraft,  a  defense 
environment,  and  bombing  mission  parameters,  a  number  of 
variables  need  to  be  initialized.  The  program  would  be 
most  flexible  if  all  the  aircraft  parameters  were 
interactively  alterable.  This  would  in  effect,  allow  any 
type  of  aircraft  to  be  simulated.  However,  in  the  interest 
of  simplicity  we  decided  to  make  the  flight  characteristics 
static,  that  is,  remain  fixed  at  their  preset  values,  but 
allow  the  ECK  and  weapon  configuration  to  be  interactively 
alterable  before  the  simulation  begins.  Enhancement  of  the 
interactive  adjustment  to  include  more  parameters  will 
improve  the  implementation.  In  particular,  the  following 
structure  will  be  used. 

Preset  Data 

A)  All  aircraft  performance  capability  (i.e.  the 
"type"  aircraft  is  constant) 

L)  The  defensive  environment  (input  from  an 
Avionics  Laboratory  database) 

C)  An  abort  mission  profile 

D)  A  predefined  flight  path 

Interactively  Alterable  Data 

A)  ECM  configuration 


1)  Number  of  Chaff  pods 

2)  Degrade  factor  for  a  chaff  pod 


jj  Murjer  of  infra-red  flares 
)  Degrade  fact  or  for  a  flare 
3)  Number  of  radar  jammers 

B)  V.'eapons  Load 

1)  Number  of  "Iron"  bombs 

2)  Number  of  "Smart"  bombs 
i)  Number  of  R?  missiles 
if)  Number  of  IR  missiles 

3)  probability  of  kill  (PN)  for  each  /weapon 
type 


The  Simulation 

Interactive  Inputs 

The  aircraft  ^ould  initially  be  a  low  level 
simulation  only,  to  be  enhanced  as  time  permitted  later  in 
the  effort.  The  menu  pick  would  allow  for  pilot  actions  as 
follow : 


A)  Turns 

Change  direction,  at  normal  or  maximum  rate 
P)  Speed 

Inc  rea  se/ deer  ease  ,  at  normal  or  maximum  rate 

C)  Altitude 

Increase/ decrease ,  at  normal  or  maximum  rate 

D)  ECM-selection 
One/ all 

E)  Bombing  mode 


F)  Resume  pre-set  flight  path 


J)  Pi  5  "5  ion  abort 

In  addition,  th^  menu  pick?!  could  be  further  defined  by 
keyboard  inputs  to  determine  the  follo/jinp; 

A)  Heading  Change 

P)  Airspeed  Change 

C )  Altitude  Change 

D)  Vhich  jammer 
t)  Direction 
2;  Frequency 
j )  power 

£  )  V'h  i  c  h  we  a  p  0  n 
V^hich  target 

F)  Simulation  timestep  -  the  time  advance  in  the 
mission  before  the  user  is  again  allowed  to 
make  inputs 

G)  "Real  time"  factor  -  a  means  to  accelerate  or 
decelerate  the  real-time  aspect  of  the 

sim  ul a  ti on 

Interactive  Outputs 

In  order  to  simulate  an  aircraft  with  an  active 
pilot,  two  requirements  exist.  The  input  data  section 
above  a  d  d  r  e  s  s  e  s  1 1.  e  means  by  which  the  pilot  controls  the 
aircraft.  The  other  requirement  is  to  simulate  the  enemy 
threats  upon  which  decisions  and  resultant  actions  are 
based  . 


The  simulation  feedback  will  be  in  four 


;j  a  r  s  : 


A  computer  generated  Itadar  V'arning  Display 
i  c  h  includes: 

1)  a  symbolic  representation  of  the  highest 
priority  enemy  threats  (SAM  sites,  AAA, 
etc  . ) 

2)  an  indication  of  degree  of  threat  based  on 
rf  signal  strength  and  radio  direction 
finding  principles 

j)  an  indication  of  the  type  of  threat  being 
displayed  (track,  acquisition,  or  launch 
mode) 

A  computer  generated  visual  representation  of 
the  threat  environment  to  include: 

1)  a  symbolic  representation  of  SAM. 
sites/type  /lithin  the  pilot's  visual 
capability 

2)  a  symbolic  representation  of  AAA 
sites/ type  within  the  pilot's  visual 
capability 

Tabulated  instrument  readings  /;hich  display 
actual  vs.  preplanned  values  for  the  follo/iing 
aircraft/mission  parameters: 

1)  elapsed  time  ( hour s :minutes : second s) 

2)  true  heading  (degrees  magnetic) 
j)  altitude  (feet) 

i4  )  ground  speed  (knots) 

b)  fuel  remaining  (thousands  of  pounds) 
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6)  total  fuel  flow  rate  (thousand?  of  pounds 
per  hour) 

7)  position  (latitude,  longitude) 

D)  Tabulated  listing  of  the  following  aircraft 
e  qu  i  pm  en  t/  st  a  t  u  s 

1)  jammer  name/ on-off,  frequency  selected, 
po  wer ,  direction 

2)  chaff/ number  of  pods  remaining 
j)  bombs/ type,  number  remaining 

!i)  cruise  missiles/ type,  number  remaining 

E)  Interactive  message  area  which  will  prompt  the 
pilot  for  keyboard  inputs  and  display  his 
selections  as  appropriate  (i.e.  degrees  of 
heading  change  for  turn,  knots  of  airspeed 
change,  etc.) 

Post  Simulation 

Since  this  project  is  an  enhancement  of  the 
capabilities  of  already  existing  simulation  software  (the 
AADEM  model),  the  previous  output  generating  routines 
should  be  coupled  to  this  project  so  that  there  is  no  loss 
of  already  existing  reports.  In  addition,  a  grapli  ical 
representation  of  the  new  flight  path  through  the  threat 
environment  should  be  made  available  to  the  user  on 
request.  The  generation  of  post  simulation  output  will  be 
considered  a  low  priority  requirement. 


Required  Fur. c tip r s 

Numerous  functions  need  to  be  performed  in  order  to 
accomplish  the  tasks  discussed  above.  In  general,  the 
capability  to  update  all  aircraft  performance  parameters, 
equipment  status  parameters,  and  defensive  site  status 
parameters  on  a  continous  time  basis  ,iill  be  required.  In 


addition  , 

several 

classes 

0  f 

function 

r>  need 

t  0 

b  e 

per  fo  rm  ed  . 

These 

incl ude , 

b  ut 

are  not 

limited 

t  0 

the 

folio  wing  : 

A)  To  support  the  interactive  pilot  actions 

requires  the  following  capabilities  : 

1)  The  capability  to  generate  a  menu  of 
potential  pilot  actions 

2)  The  capability  to  interpret  user  inputs  in 
a  unique  manner  , and  to  gracefully  recover 
from  illegal  inputs. 

3)  The  capability  to  prompt  for  furth.er 
definition  of  pilot  desires  when  needed. 

)  The  capability  to  modify  the  mission 

profile  so  that  the  "aircraft"  correctly 
responds  to  "pilot"  inputs 

5)  The  capability  to  determine  current 

aircraft  position  based  on  the  combination 
of  preset  mission  profile,  pilot  inputs 
and  elapsed  time 

b)  The  capability  to  store,  update  and 


display  aircraft  status  parameters 


'  j  :r  ♦frfdc-i  bet  w-e-en  the  existing  Av  i  t  r.  i  c  s 

Laboratory  simulation  and  the  tn  a  n- i  r- 1  c  o  p 
simulation  requires  the  following 
capabilities : 

1)  The  capability  to  interpolate  aircraft 
position  on  a  continuous  time  scale  as 
desired  from  the  discrete  position  vs. 
time  values  supplied  by  the  predefined 
flight  path 

2)  The  capability  to  determine  relative 
position  of  the  aircraft  and  air  defense 
sites  on  a  continuous  time  basis  from  the 
discrete  data  furnished  in  the  defense 
environment  data  bases 

j)  The  capability  to  determine  when  either  a 
defensive  site  or  the  aircraft  has  been 
destroyed 

C)  To  generate  the  Radar  Warning  Receiver  display 
and  the  pilot's  visual  display  require  the 
following  capabilities: 

1)  The  capability  to  draw  the  various 
geometric  figures  which  combine  to  build 
the  display 

2)  The  capability  to  translate  the  X-Y 
viewport  coordinates  so  that  the  aircraft 
and  threats  are  displayed  in  the  correct 
relative  position 
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3)  The  capability  to  update  the  display 
periodically 

The  above  outline  describes  precisely  </h  a  t  this 
system  should  do.  The  next  step  in  software  development  is 
to  determine  how  the  system  will  do  it. 


0^* 


35 


i 


The  delpy  multiplier  is  used  to  plter  the  real  time 
aspect  of  the  simulation.  The  aelay  is  the  clock  time 
between  how  long  it  takes  to  update  all  simulation 
parameters,  and  the  timestep.  This  is  the  input  parameter 
to  the  wait  function.  You  can  accelerate  the  simulation  by 
multiplying  the  delay  by  a  number  less  than  one.  You  can 
slow  the  simulation  by  using  a  number  greater  than  one. 

There  are  two  displays  available  depending  on  the 
strategy  of  the  user  at  the  time.  The  defensive  display 
(Figure  II)  gives  a  Padar  Warning  Receiver  and  ECM  Status. 
The  offensive  display  (Figure  12)  gives  a  top  down  visual 
presentation  and  weapon  status.  The  other  three  parts,  the 
interactive  scratch  pad  at  upper  left,  interactive  menu  at 
upper  right,  and  mission  status  at  lower  left  are  always 
presented  . 


Given 

this 

general 

description 

0  f 

the  program 

structure  , 

I  will 

go 

on 

to  discuss 

the 

testing 

and 

veri f ication 

.  For 

more 

information  on 

exactly  what 

the 

program  can 

do  ,  or 

how 

i  t 

does  it  ,  I 

refer 

you  to 

t  h  e 

User's  Guide,  Appendix  IV. 
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Testing  is  the  process  of  executing  d  program  with 
the  intent  of  finding  errors.  This  implies  that  a  good 
test  case  is  one  that  has  a  high  probability  of  detecting 
an  as  yet  und  i  sc  o  v  er  ed  -arror.  The  first  section  of  this 
chapter  will  discuss  the  principles  of  testing  in  general 
terns.  T'he  second  section  will  then  discuss  the  thesis 
project  in  particular. 

In  General 

Testing  can  be  divided  into  two  main  classes;  "black 
box"  testing  and  "glass  box"  testing  (sometimes  referred  to 
as  "white  box"  testing).  In  black  box  testing,  the  test 
data  is  derived  solely  from  the  project  specifications. 
Often  the  lest  cases  for  a  software  project  are  written 
before  or  during  the  actual  software  development.  These 
tests  are  mostly  to  insure  that  the  software  does 
everything  it  is  specified  to  do. 

For  example,  suppose  a  module  is  supposed  to  sort  up 
to  fifty  names,  each  with  up  to  twenty  characters,  into 
alphabetical  order.  The  most  common  first  test  would  be  to 
feed  it  a  list  of  names  and  be  sure  that  the  output  is 
al phabeti zed .  Another  common  test  would  be  to  ensure  that 
it  handles  too  large  an  input  file  (say  b1  names) 
reasonably.  Also.  Joes  it  handle  the  cases  of  zero  or  one 


name?  These  are  the  boundary  conditions,  and  should  always 
be  tested.  Often  in  testing,  due  to  the  potentially  large 
number  of  possible  cases,  situation  s  are  broken  into 


equivalenc 

e  class 

e  s  . 

Th  a  t 

i  s  , 

i  f 

t  h.  e  sort  routine 

gr  ace  full y 

handles 

0  1 

n  am  e  s  , 

h*  0  p  e 

f  ul 

1  y  the  same  error 

handler  is 

called 

for 

larger 

files 

• 

5-.^  e..  ^  d.'i 

equivalent  in  a  sense,  and  th.ey  probably  don't  need  to  be 
tested  individually.  Similarly,  if  the  routine  correctly 
sorts  2,  2o,  and  30  elements,  chances  are  it  /vill  handle 

tl.e  numbers  between.  The  number  of  characters  in  the  names 
would  be  tested  in  the  same  way  as  the  number  of  names  in 
the  file. 

This  brings  up  a  point  on  efficient  testing. 
V.'henever  a  test  is  supposed  to  work  according  to  the 

specifications,  any  number  of  situations  may  be  tested 
simultaneously.  So  we  could  test  a  name  with  only  one 
character,  one  with  twenty,  and  a  list  of  fifty  names  all 
in  the  same  run,  and  expect  an  alphabetized  list.  However, 
when  our  test  is  designed  to  be  outside  specifications, 
each  case  must  be  handled  separately.  This  is  to  ensure 
that  each  invalid  case  is  correctly  handled.  And  finally, 
the  tester  must  always  know  the  expected  output  before 

executing  1 1. e  test.  It  is  very  easy  to  loci:  at  output  that 
is  close  to  correct,  and  ass  urn e  it  is  perfect. 

The  0 1  h.  e  r  c  1  a  s  s  of  testing  is  glass  box  testing. 

These  t^sts  take  advantage  of  knowledge  of  the  internal 


?!ub."icript.  ranges,  divisors,  loop  control,  etc.,  ano  are 
designed  to  find  overlooked  situations  ^jhich  ^rill  cause 
pr  ob 1 em  s  . 

Poth  classes  of  testing  often  incorporate  "error 
guessing."  An  experienced  programmer  considers  the  problem 
at  hand,  tries  to  guess  the  potentially  troublesome  cases, 
then  tests  that  the  program  adequately  performs  these 
cases  . 

Program  testing  is  where  the  programmer  is  paid  back 
for  segmenting  code  into  routines  which  perform  one  well 
defined  function.  Each  subroutine  can  be  tested  using  the 
techniques  discussed  above  by  calling  it  with  a  simple 
driver.  If  the  function  is  performed  correctly,  the  only 
question  remaining  is  whether  the  tests  were  adequate.  If 
the  function  is  not  performed  correctly,  there  Is  no 
question  as  to  which  routine  is  at  fault.  V’her.  a  given 
routine  passes  its  tests,  other  routines,  at  that  level  are 


s  i  m  i  1  a  r  1 

y  tested. 
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driver 
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a  giver*  set  of  tests  is  sufficient,  *i(hile  being  less  than 
ex  haust iv  e . 

Pefore  moving  to  the  specifics  of  ny  project,  ’here 
are  a  few  other  principles  of  testing  often  highlighted  in 
the  literature:  [Ref  ij,  P,  11,  12,  I3] 

A)  A  necessary  part  of  a  test  case  is  the  definition 
of  expected  results. 

Pj  A  programmer  should  avoid  attempting  to  test  his 
or  her  own  p  r  0  g  r  am  s  . 

C)  The  probability  of  more  errors  in  a  section  of  a 
program  is  proportional  to  the  number  of  errors 
already  found  in  that  section. 

D)  Examining  a  program  to  see  if  it  does  not  do  what 
it  is  supposed  to  is  only  half  of  the  task  -  the 
other  half  is  seeing  whether  the  program  does 
what  it  is  not  supposed  to  do. 

With  the  above  philosophies,  techniques  and  tools,  we’re 
ready  to  test  the  simulation. 

The  Simulation 

The  basic  rule  of  software  testing  -  avoid  testing 
your  own  work  -  was  unfortunately  impossible  to  follow  for 
this  effort.  I  did,  however,  attempt  to  test  the  project 
thoroughly.  There  are  eleven  general  functions  which  make 
u p  t  h  i  s  so  ft  wa  r  e  : 

1  )  Text  displays  are  presented  on  1 1* e  screen 

2)  parameters  are  input  from  files 


bO 


Pd  r  an  ^  V -e  r  are  i  . 

LLr. /;•.  ;■■!.  ar-  '  I  _■  • -j ~  f  :■  r  -iv -ir  y  Jii^play  ar-e 

;i  r  d  <^lr^ 

3  )  V.'o  r  j  //i.  i  c  P.  a  r  r?  t  P.  e  .*•,  a  n  e  for  e  v  a  r  y  j  i  •!  p  lay  a  r  a 

/jr  i  1 1  an 

^5)  Linen  for  tP.e  offennive  _oj^  defennive  dir, play  are 
d  r  a  A/n 

7)  I'ords  for  the  offensive  _or  defensive  display  are 
^r  i  1 1  en 

P)  Interactive  commano*  are  decoded 

9)  parameters  are  updated 

10)  Parameters  are  printed 

11)  Site  information  is  graphically  displayed 

It  would  be  tedious  and  very  dry  to  explicitly  state  every 
test  case,  reason  for  use,  and  expected  outcome  for  each 

subroutine,  so  I  will  describe  th.  e  testing  in  slightly 

higher  terms  for  the  higher  level  functions  described 

above. 

1 )  Text  Displays 

.<tll  text  displaying  routines  are  merely  a  call  to 
set  the  character  size,  then  a  sequence  cf  rOT^THAN'  print 

statements.  No  parameters  are  input,  and  no  variable  are 
changed.  for  these  modules,  exhaustive  testing  is  simply 
to  read  tP.  e  output  for  typograhioal  errors,  and  format  on 
the  screen. 
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2  A  j  )  I  r.  p  u  t  ?  r  c  m  r  i  1  ■:;  .'s 

All  robtin-iS  which  read  inp'jh  files  to  initidli7e 
variables  were  tested  by  using  a  parallel  routine  with 
shared  common  areas  and  write  instead  of  read  statements. 
V’hen  all  variables  written  were  the  same  as  the  variables 
read,  I  considered  the  input  routines  to  be  sufficiently 
tested  . 

^  d  )  Static  Display  Drawing 

The  static  line  drawing  and  word  writing  routines  are 
in  the  same  category  as  1  above.  V'hen  the  lines  are  in  the 
desired  places  with  the  correct  words,  in  the  proper 
position,  in  the  proper  text  size,  the  testing  is 
e  X  h  a  u  s  t  i  V  e  . 

6^7)  Dynamic  Display  Drawing 

Testing  the  static  drawing  for  the  offensive  display 
(Visual  Display  and  Current  V/eapon  Status)  or  defensive 
display  (Radar  V/arning  Receiver  and  Current  ECt'  Status)  is 
only  a  small  step  from'  ^4  &  5  above.  Each  subroutine  was 
first  tested  with  a  driver  until  the  words  and  lines  were 
as  desired.  V'hen  this  was  satisfactory,  they  were  coupled 
to  tl'.e  refresh  driver,  to  check  that  the  two  displays 
toggled  back  and  forth  correctly. 

P.  )  Interactive  Command  Decoding 

The  interactive  command  handling  routine  was  coded 
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and  t'isted  in  very  mail  sieps.  Testing  «a  •;  no  more 

complicated  than  for  the  *,  ituations  above,  but  .*!ince  there 

are  seventeen  boxes  in  the  menu,  t  ^lz  buttons,  and  six 

control  characters,  it  took  considerably  longer.  f’y 

routine  calls  the  cursor,  c  t;  e  e  k  s  for  a  control  c  h  a  r  a  c  t  e  r  , 
checks  for  the  space  bar,  and  if  none  of  t  h.  e  above,  loops 
back  to  call  the  cursor.  I  tested  every  c  h.  a  r  a  c  t  e  r  on  the 
keyboard  to  insure  that  none  of  the  ASCII  codes  /jould  be 

m i s in t er pr e 1 1 ed  .  Since  the  cursor  handler  of  HLOT-10 
returns  a  single  cl. aracter,  plus  the  X,  Y  coordinate  of  the 
point,  I  believe  that  it  is  unnecessary  to  ivorry  about 
combinations  of  characters  causing  problems.. 

.=  or  each  control  character,  and  the  space  bar,  I 
initially  had  the  routine  vrite  a  message  /th-in  selected. 
V’hen  I  fia*.  convinced  that  this  structure  /va  s  correct,  I  did 
the  same  for  the  X,  Y  picking  of  buttons  and  menu  boxes. 
V'hen  the  exclusive-or  structure  //as  confirmed  I  replaced 

each  message  //rite  statement  //ith  a  call  to  a  subroutine 

//ith  the  respective  //rite  message.  V'hen  each  box  and 

button  vas  tested  this  //ay,  I  //ent  on  to  //rite  a  functional 
nodule  to  perform  the  respective  task.  These  functional 
modules  //ill  be  discussed  next. 

9  &  1 0 )  Updating  and  printing  parameters 

There  are  t //o  types,  of  parameters,  to  update  during 
the  simulation:  ’’counters"  and  ’’ po  .s  i  t  i  on  s  .’’  The  cour.  ter.s 

include  chaff,  flares,  and  //rjapons,  remaining,  elap.sad  tine. 


dnd  f'j-el  flO/j.  Cc"ip'jting  tK-in-e  involve.*'  .lirnpie  s 'jb  t  r  ac  t  i  o  r. 
for  i  t  e  m  .*•  r  e  n  c  ^  r.  i  n  g  ,  e  ,i  ;  i  i  t  i  o  r  for  e  1  a  p  .r  e  d  ^  i  m  e  ,  e  r.  d 
periodic  addition  and/or  .■subtraction  to  fuel  flov 
de.spending  on  //!*at  maneuver.'s  are  taking  place.  Te.*!ting 
involve. ■s  boundary  testing  to  preclude  negative  number.',  of 
item.?  remaining,  and  c  o  r  r  e  c  t  n  e  .s  s  testing  for  1 1.  e 
combinations  of  events.  "position"  parameters  include  V 
position,  Y  position,  fuel  remaining,  ground  speed, 
altitude,  and  heading.  As  mentioned  previously,  all  of 
these  values  are  computed  by  the  scheme; 

t'-i  j)  value  =  Old  value  +  (change  rate  *  time). 

Insuring  the  needed  common  blocks  ;;ere  available,  and  that 
the  specific  formulas  had  no  typographical  errors  s  the 
crucial  part  of  this  testing.  The  simulation 
repeatedly  advanced  by  one  second  ana  stopped  so  that  each 
parameter  coud  be  checked  through  several  cycles  and  a 
representative  cross  section  of  maneuvers.  Since  the 
printing  of  these  parameters  is  done  by  converting  the 
internally  stored  values  from  integers  and  real  numbers  to 
character  strings,  then  using  graphics  text  output  features 
from  PLOT-1  0,  any  incorrect  output  could  have  been  caused 
either  by  1 1.  e  c  o  n  v  e  r  s  i  o  n  routines  or  the  a  r  i  r  h  m  e  t  i  c 
computation.  I  tested  the  boundaries,  and  error  guessed 
/»hen  appropriate,  trying  to  cause  the  routines  to  fail.  I 
believe  these  routines  are  correct. 
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Equations 

This  appendix  discusses  two  aspects  of  the 
mathematics  used  in  the  MIRAGE  system  which  are  not  readily 
apparent  either  from  reading  the  body  of  this  thesis,  or 
from  studying  the  code.  The  first  section  of  the  Appendix 
discusses  the  derivation  of  the  signal  strength  of  a  radar 
signal  received  at  the  aircraft  which  was  used  in 
constructing  the  Radar  Warning  Receiver  Display.  (Recall 
that  the  RWR  displays  the  relative  bearing  of  sites  with 
respect  to  the  aircraft,  and  the  strength  of  the  received 
radar  signal.)  The  second  section  gives  a  brief  error 
analysis  for  the  approximations  used  throughout  the 
simulation . 

Radar  Equations 

The  A.  ADE^i  model  presets  all  aircraft  parameters  and 
observes  maneuver  success  from  the  ground  environment's 
viewpoint.  The  MIRAGE  system,  on  the  other  hand, 
interactively  adjusts  the  aircraft  parameters,  and  displays 
data  from  the  aircraft's  viewpoint.  This  required  that 
some  radar  signal  parameters  used  by  the  AADEM  model  be 
"backed  up"  to  the  aircraft  perspective. 

In  order  to  construct  the  Radar  Warning  Receiver,  the 
echo  pulse  power  received  at  the  aircraft  of  the  radar  from 
each  site  was  needed. 
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The  equation  for  this  is: 

S  ^  =  (P4.  •  G*.  •  Loss)/4frr^  ‘ 
ac  t  t 

where : 

S  s  echo  pulse  power  (signal  strength)  received 

d  C 

at  the  aircraft 

=  peak  power  of  the  transmitted  signal 
G^  =  gain  of  the  antenna  in  the  direction  of  the 
target 

r  s  slant  range  between  radar  site  and  aircraft 
[kef  14:2.6-2.7] 

Howevert  since  the  AADEM  model  uses  the  site’s 
perspective,  it  deals  with  signal  strength  reflected  to  the 
site.  This  equation  is  similar,  but  is  affected  by  the 
...  cross-section  area  of  the  aircraft,  twice  the  distance,  and 

I  Q? 

the  affective  area  of  the  receiving  antenna. 

Specifically, 

S  =((P  *0  •loss)/4nr^)«((Xsec*loss’*A  )/4itr^) 

I  si te  t  t  '  r 

=S„  »(Xsec/4irr^)«l6ss’*A 

S  X  V  G  d  C  1? 

^ac  =S3i(.g»((4ifr^/(Xsec«loss'«A^)  ) 

where : 

A  =  area  of  the  receiving  antenna 
r 

An  equation  was  needed  which  determined  the  one  way  loss, 
I  and  "unfigured"  the  affect  of  aircraft  cross-section  and 

the  receiver  antenna.  In  subroutine  STfiNTH,  RLOSS  is  a 
computation  which  determines  the  one-way  loss  needed  from 
the  two-way  loss  available  in  AADEM.  FACTOR,  then,  is  the 
solution  to  the  equation  discussed  above  expressed  in  terms 
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of  the  AADEM  variables  and  RLOSS.  Precise  definitions  for 
the  AADEM  variables  used  are  available  in  the  AADEM 
documentation. 

Error  Analysis 

Althou5;h  this  section  in  entitled  error  analysis,  it 

should  be  emphasized  that  the  MIRAGE  system's  equations  are 

exact  except  when  the  aircraft's  speed  or  direction  are 

changing.  In  comparsion  to  its  total  mission  time,  this 

should  be  a  relatively  small  percentage.  For  simplicity, 

consider  the  two  cases  disjoint.  The  worst  case 

performance  will  be  no  more  than  the  sum  of  the  two  errors. 

First  look  at  the  case  of  constant  heading,  with  a 

constant  acceleration  or  deceleration.  Also,  assume  that 

our  velocity  is  totally  in  the  X  direction. 

We  know  that  velocity  s  V  =  dx/dt 

and  acceleration  =  a  =  d\fc/dt. 

Then  V(t)  =  V  +  fa  dt  =  V  +  at 
Os  o 

In  the  MIRAGE  system  a  is  constant  and  for  any  time 
Increment,  At, 

♦  a  t )  d  t 
2 

AX  =  V  t  +  (1/2)a  t  I  when  acceleration  is  constant 
o  •• 

AX  =  V  At  +  (1/2)  a  (At)^ 
o 

The  MIRAGE  system  approximates  using.  Ax  =  ^Q^t 

2 

Thus  the  error  =  (1/2)  a  At 
and  %  error  s  ((1/2)  8At^)/(V^At)  "  100 
=  [(1/2)  sAt/V^]  »  100 


At  a  typical  cruise  airspeed  of  400K  using  the  maximum 


acceleration  of  15K/sec  and  /^t  of  1  second  as  used  In 
MIRAGE  , 

>  error  =  [(1/2)  •  (15)  •  (l)/400]  •  100  =  1.875% 


For  the  second  case,  consider  constant  airspeed,  but 
a  turn.  Me  will  consider  a  standard  X,  Y  coordinate  system 
with  measured  positive  clockwise  from  the  +Y  axis. 


+Y 

/ 

••■X 

FIGURE  13 
Theta  Measurement 


Then  the  X  component  of  the  velocity  =  V  Sin  ^ 

Let  w  =  turn  rate  =  d^dt 

and  AX  s  V  ^Sin‘d(t)  dt  where  ^(t)  =  wt  » 

Ax  =  V  ^Sin  (^♦wt)  dt 
Let  (P  s  '6ii  -f  wt  then  d  w  dt  ->  dt  =  d  (P/w 
then  Ax  =  V  ^in  (4)  w  d^ 

.  ,At 

=  (V/w) [-Cos  ^  )  I 

•O  -a. 

r (-V/w) [Cos  (^  ♦  Wt)  ]  I 
=  (-V/w)  [Cos(^-»  wAt)  -  Cos4i] 


£.  !• 


For  example,  let  ■^2  then 

uAx  =  (-V/w)  [Cos('^2  ♦  wAt)] 

=  (-V/w)  [Cos  ^.2  Cos  wAt  -  Sin  Sin  wAt] 

=  (-V/w)  [-Sin  wAt] 
he  know  the  Maclaurin  series  of 

Sin  X  =  X  -  (X^/3!)  +  (X^/51)  -  (X^/7!)  .  .  . 
so  4x  S  (V/w)  [(wAt)  -  (w4t)^/3ll  using  the  first  two  terms 
of  the  series 

4x  S  VAt  -  (Vw^At^)/6 
The  MIRAGE  system  uses  Ax  S  VAt 
which  has  error  approximately  V  w  Af/S 
and  i  error  -  [  (  ( Vw^ At^ ) /6 )  /  VAt  ]  •  100 
.s  [(w^At^)/6]  «  100 
In  MIRAGE,  At  s  1  sec 

maximum  w  s  18  degrees/sec  s.3li|1592  radians/scc 

Thus  %  error  =  (.31^*1592)^  »  (1)^  »  100  /  6  =  1.6'»'»93X 

2 

Since  %  error  grows  as  At  in  the  second  case, 
clearly  a  At  much  greater  than  one  would  cause 
significantly  larger  errors.  A  smaller  At  would  reduce  the 
error,  but  I  feel  that  these  errors  are  tolerable  as  it 
stands.  If  a  future  user  disagrees,  i<t  requires  a  simple 
edit  in  the  data  statement  for  "DT"  in  subroutine  CINITL  to 
reduce  the  %  error  as  desired. 
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Appendix  II 
SADT  Descriptions 

This  appendix  contains . the  complete  SADT  description 
for  the  MIRAGE  software  system.  .  Recall  that  one  criterion 
for  stopping  the  decomposition  of  a  function  is  that  the 
function  can  be  accomplished  by  a  known  tool.  Since  the 

MIRAGE  software  system  interacts  with  the  AADEM  model  , 
several  AADEM  routines  were  used  as  tools.  This  explains 
why  the  following  nodes/boxes  were  not  decomposed  further. 
Node  A  125  box  1 
Node  A 125  box  2 
Node  A22  box  3 
Node  A23  box  I 
Node  A23  box  2 


f 
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Predefined 
Flight  Path 


Kode  AO  1  An  Interactive  Eombine  Mission  Simulation 
I  vith  Computer  Graphics  Interface 


Node  A111  !  Analyze  Graphic  Terolnal  Inputs 


Node  A112  i  Modify  Aircraft  Parameters 


ze  Graphic  Terminal  Input 


Present 

Positio 


Prese 

Posit 


Node  A21  i  Compute  Aircraft  Status 


Current 
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Node  A22  I  Compute  ECM  vs  Padar  Effects 
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Node  A23  i  Compute  Weapon  Effects 


(i-  ^Lr  ) 

:  r.  ■<  t  i  r  R  i.  T  1  1  "’L  ,  Sf:'"i-i- 

A V <'.t:  fuel  use  rate,  full  throttle,  at  flight 

altitude 


NAME  : 
TIPE: 
USE: 

PURPOSE  : 


£Ua 

Local  variable 
Subroutine  LVLOFF,  SETSPD 

Indicates  whether  from  a  climb  or  a  descent, 
acceleration  or  deceleration 


NAME  : 

TYPE  : 
PURPOSE  : 
CALLS  : 
CALLED  BY: 


£Li££ 

Subroutine  name 

Responds  to  the  pilot  picking  the  "F"  button 
FLYAC 


NAME  : 
TYPE: 
USE: 

PURPOSE : 


CLOWCM 

Local  variable 
Subroutine  SETFF,  RSETFF 

Input  parameter  -  amount  to  change  fuel  use 
rate 


NAME ; 
TYPE: 
USE; 

PURPOSE : 


£L£,aAM 

Common  block  name 

Subroutine  GINITL,  DESCND,  CLIME,  DECEL,  ACCEL, 
TURN 

Fuel  use  rate  adjustment  for  transient  flight 
states 


NAME : 
TYPE  : 
USE; 

PURPOSE ; 


ELBDEG 

Common  variable  (ECMDEG) 
Subroutine  GINITL,  WRITER 
Degrade  factor  for  flare 


NAME  : 
TYPE  : 
PURPOSE : 


CALLS: 


CALLED  BY: 


£L1A£ 

Subroutine  name 

Responds  to  the  pilot's  menu  picks 

Prompts  pilot  for  information  as  required 

Sets  simulation  status  flag  to  indicate  that 

the  aircraft  is  in  a  transient  state 

Calls  appropriate  subroutines  to  adjust  the 

aircraft  position  accordingly 

DCURSR,  REFRSH,  MOVABS,  ANSTR,  ANMODE,  HELP, 
CHAFF,  FLARE,  ABORT,  RESUME,  WEAPON,  JAMMER, 
LVLOFF,  DESCND,  CLIMB,  SETSPD,  DECEL,  ACCEL, 
ROLOUT,  TURN,  ENDG 
PROCES 


NAME  : 
TYPE: 

USE  : 

PURPOSE: 


£afca-i^i- 

Common  variable  (JAMM) 

Subroutine  GINITL,  INPUT,  ECMVAL,  JAMMER 
Frequency  setting  of  respective  Jammer 
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NAME : 

TK  PE  : 

USE  : 

PURPOSE  : 


J 

Local  variable 
Subroutine  ST R NTH 
Constant  -  (ll^Pi)*^ 


NAME  : 
TYPE  : 

USE : 

PURPOSE : 


FSTING 

Common  variable  (STATUS) 

Subroutine  GINITL,  FLYAC,  S'^’ATVL 
TRUE  when  aircraft  ij  accelerating 


NAME  : 
TYPE  : 

USE  : 

PURPOSE  : 


£ii£L^ 

Common  block  name 

Subroutine  GINITL,  SETFF,  RSETFF 

All  global  information  relating  to  aircraf 

fuel 


NAME  : 
TYPE : 

USE : 

PURPOSE ; 


Common  block  name 

Subroutine  GINITL,  SETFF,  RSETFF,  WEAPON 
Aircraft  fuel  use  rate  parameters 


NAME  : 
TYPE  : 

USE ; 

PURPOSE  : 


mpAi 

Common  variable  (FUELS) 
Subroutine  GINITL,  SETFF,  RSETFF 
Fuel  use  rate 


NAME  : 
TYPE  : 
USE; 

PURPOSE : 


mX£LI 

Common  variable 
Subroutine  GINITL,  STATVL 
Total  fuel  remaining 


NAME  : 

TYPE  : 
PURPOSE : 

CALLS : 
CALLED  EY: 


G£TTGT. 

Subroutine  name 

Plots  enemy  sites  for  the  visual  display  an 
gets  user  pick  for  target 
PLTSIT,  PIKSIT 
WEAPON 


NAME  : 

TYPE: 
PURPOSE : 

CALLS: 
CALLED  EY: 


milk 

Subroutine  name 
Initializes  all 
simulation . 


START 

PRELIM 


global  variables  used 


in  th 


NAME  : 

TYPE: 
PURPOSE  : 
CALLS: 
CALLED  EY: 


Subroutine  name 

Refreshes  the  screen  and  calls  for  pilot  inputs 
REFRSH,  CHRSIZ,  ANKODE,  MOVABS,  ANSTR 
PHOCES,  PRELIM,  JAMMER 


NAME : 
TYPE  : 
USE: 

PURPOSE : 


ssmus 

Common  block  name 
Subroutine  SETDEV,  ENDG 
All  global  graphics  information 


NAME : 
TYPE : 
USE: 

PURPOSE: 


HDG 

Common  variable  (ACSTAT) 

Subroutine  TURN,  ROLOUT,  GINITL,  PIKSIT,  PLTSIT 
Current  heading  of  the  aircraft 


NAME: 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 


ii£L£ 

Subroutine  name 

Prints  information  on  how  to  operate  the 
simulation 

CHRSI2,  NEWPAG,  ANMODE 
FLYAC,  GETTGT,  INF03,  PIKSIT 


NAME  : 

TYPE: 
PURPOSE: 
CALLS; 
CALLED  BY; 


Subroutine  name 

Hides  the  interupt  character  echo 

CHRSIZ,  MOVABS,  ANMODE 

PROCES 


NAME  : 

TYPE; 

PURPOSE: 

CALLS: 

CALLED  BY: 


iUIMJl 

Subroutine  name 

Handles  functions  if  the  aircraft  inadvertently 
is  flown  into  the  ground 

NEWPAG,  CHRSIZ,  MOVABS,  ANSTR,  ANCHO,  GSETUP, 
ANMODE,  BOXER,  WAIT,  LVLOFF 
STALL,  STATVL 


NAME : 
TYPE  ; 
USE: 

PURPOSE : 


Common  variable  (WEPPKS) 

Subroutine  GINITL,  INPUT,  WEAPON 
Probability  of  kill  for  an  IR  missile 


NAME : 
TYPE; 
USE: 

PURPOSE; 


ill 

Local  constant 
Subroutines  WORDS 

Y-coordinate  in  absolute  units  of  the 
line  on  which  to  write  MAX  in  the  menu 


lowest 


NAME : 
TYPE: 
USE: 

PRUPOSE; 


NAME : 
TYPE  ; 

USE : 

PURPOSE: 


Local  variable 
Subroutine  WRITER 

Extractions  from  common  blocks  to  be  written  in 
the  dynamic  portion  of  the  interactive  display 


Local  variable 
Subroutine  WORDS 

ASCII  equivalent  of  ABORT  MISSION 


NAME: 

TiPE: 

USE: 

PURPOSE : 

NAME  : 
TYPE: 
USE: 

PURPOSE: 

NAME  : 
TYPE: 
USE: 

PURPOSE: 

NAME  : 
TYPE: 
USE: 

PURPOSE : 

NAME: 
TYPE  : 
USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME : 
TYPE: 
USE: 

PURPOSE: 


NAME: 
TYPE  : 
USE: 

PURPOSE : 

NAME : 
TYPE : 
USE: 

PURPOSE: 

NAME: 
TYPE  : 
USE: 

PURPOSE : 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  ACCELERATE 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  ACTUAL 


Local  variable 
Subroutine  WORDS 

ASCII  equivalent  of  ALTITUDE  (AGL) 


Local  variable 
Subroutine  WORDS 

ASCII  equivalent  of  BOMBING  MODE 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  CLIMB 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  DECELERATE 


Local  variable 
Subroutine  FLYAC 

ASCII  equivalent  of  ENTER  DEGREES> 
Prompt  for  pilot  input 

Local  variable 
Subroutine  FLYAC,  TURN 
Heading  change  parameter 


Local  variable 
Subroutine  FLYAC 

ASCII  equivalent  of  ENTER  DELAY  MULTIPLIER 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  DESCEND 


NAME:  IlilBEC 

TYPE:  Local  variable 

USE:  Subroutine  TURN 

PURPOSE:  Input  paramenter,  indicates  direction  of  turn 

NAME:  1£M1 

TYPE:  Local  variable 

USE:  Subroutine  FLYAC,  DESCND,  CLIMB 

PURPOSE:  Altitude  change  parameter 

NAME:  IFIRST 

TYPE:  Local  variable 

USE:  Subroutine  WRITER 

PURPOSE:  Loop  parameter 


NAME: 
TYPE : 
USE: 

PURPOSE : 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  FLIGHT  PATH 


NAME : 
TYPE : 
USE: 

PURPOSE: 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  FUEL  FLOW 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 
Subroutine  JAMMER 

ASCII  equivalent  of  ENTER  FREQUENCY> 


NAME : 
TYPE: 
USE: 

PURPOSE : 


Local  variable 
Subroutine  WORDS 

ASCII  equivalent  of  FUEL  REMAINING 


NAME : 
TYPE: 
USE: 
PURPOSE 


Local  variable 
Subroutine  WORDS 

ASCII  equivalent  of  TRUE  HEADING. 


NAME:  ILA&I 

TYPE:  Local  variable 

USE:  Subroutine  WRITER 

PURPOSE:  Loop  parameter 


NAME:  ILMfifi 

TYPE:  Local  constant 

USE:  Subroutine  DRLINE 

PURPOSE:  Left  edge  of  the  menu 


NAME: 

TYPE: 

USE: 

PURPOSE; 


NAME: 

TYPE: 

USE: 

PURPOSE : 

NAME  : 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 

NAME  : 

TYPE: 
PURPOSE : 

CALLS: 
CALLED  BY: 

NAME: 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 

NAME  : 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 

TYPE : 

USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE : 


IMSIin 

Common  variable  (TSTEP) 

Subroutine  INPUT,  GINITL,  FLYAC 

Time  increment  that  the  simulation  "runs" 
between  prompts  for  input 

IM&L 

Common  variable  (II) 

Subroutine  CTRLC, 

Flag  to  indicate  that  an  interrupt  has  occured 

Subroutine  name 

Prints  information  about  the  aircraft  flight 
characteristics 

CHRSIZ,  NEWLIN,  ANMODE,  HDCOPY,  NEWPAG 
PRELIM 

imiz 

Subroutine  name 

Prints  information  about  aircraft  configuration 
capability 

CHRSIZ,  NEWLIN,  ANMODE,  NEWPAG 
PRELIM 

imn 

Subroutine  name 

Prints  information  about  the  simulation 
graphics  displays  and  control  characters 
CHRSIZ,  NEWLIN,  ANMODE,  HELP 
PRELIM 

Subroutine  name 

Interactive  input  routine  to  configure  the 
aircraft  prior  to  running  the  simulation 
CHRSIZ,  NEWPAG,  ANMODE 
PRELIM 

Local  variable 
Subroutine  RWRPLT 

Counter  for  number  of  sites  within  radar  range 


Local  variable 

Subroutine  JAMMER 

ASCII  equivalent  of  INVALID  INPU' 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  POSITION 
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J.  > 


V] 


NAME : 
TYPE : 
USE: 

PURPOSE; 

NAME : 
TYPE: 
USE: 

PURPOSE; 

NAME: 
TYPE : 
USE: 

PURPOSE; 

NAME  : 
TYPE: 
USE: 

PURPOSE ; 


NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 
TYPE : 
USE: 

PURPOSE : 

NAME : 
TYPE : 
USE: 

PURPOSE : 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  PREPLANNED 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  PREPLANNED 


Local  variable 

Subroutine  JAMMER 

ASCII  equivalent  of  ENTER  P0WER> 


Local  variable 
Subroutine  RWR 

ASCII  equivalent  of  RADAR  WARNING  RECEIVER 
DISPLAY 


Local  variable 

Subroutine  WEPWDS 

ASCII  equivalent  of  IRON  BOMBS 


Local  variable 
Subroutine  FLYAC 

ASCII  equivalent  of  ENTER  A  POS  REAL  # 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  RESUME 

Common  variable  (WEAPNS) 
Subroutine  GINITL,  INPUT 
Number  of  rf  missiles  available 

Local  constant 
Subroutine  DRLINE 
Right  edge  of  the  menu 

Common  variable  (WEAPNS) 
Subroutine  GINITL,  INPUT 
Number  of  IR  missiles  available 
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NAME: 

TYPE : 

USE: 

PURPOSE: 

IRMISS  (11) 

Local  variable 

Subroutine  WEPWDS 

ASCII  equivalent  of  IR  missiles 

NAME : 

TYPE: 

USE: 

PURPOSE: 

Common  variable  (WEAPNS) 

Subroutine  GINITL,  INPUT 

Number  of  "Iron  bombs"  available 

NAME  : 

TYPE : 

USE: 

PURPOSE: 

Local  variable 

Subroutine  WORDS 

X-coordlnate  In  absolute  units  of  the  menu  key 
words 

NAME: 

TYPE: 

USE: 

PURPOSE: 

Local  variable 

Subroutine  JAMMER 

ASCII  equivalent  of  ENTER  SECTOR> 

NAME  : 

TYPE: 

USE: 

PURPOSE: 

ISECTR  (5) 

Common  variable  (JAMM) 

Subroutine  GINITL,  INPUT,  ECMVAL,  JAMMER 
Sector  respective  jammer  Is  jamming 

NAME: 

TYPE: 

USE: 

PURPOSE: 

Common  variable  (WEAPNS) 

Subroutine  GINITL,  INPUT 

Number  of  "smart  bombs"  available 

NAME  : 

TYPE: 

USE: 

PURPOSE: 

ISPEED  (12) 

Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  GROUND  SPEED 

NAME: 

TYPE: 

USE: 

PURPOSE : 

ISIKL 

Local  constant 

Subroutine  CIRCLE 

Roundness  factor  for  the  circle 
algorithm . 

drawing 

NAME: 

TYPE: 

USE: 

PURPOSE : 

Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  ELAPSED  TIME 

NAME : 

TYPE : 

USE: 

PURPOSE: 

IIMBIB-ilSJ 

Local  variable 

Subroutine  FLYAC 

ASCII  equivalent  of  ENTER  TIMESTEP> 
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TYPE  : 

USE: 

PURPOSE 


Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  TURN  LEFT 


NAKE  : 
TYPE: 
USE: 
PURPOSE 

NAME  : 
TYPE: 
USE: 
PURPOSE 


NAME  : 
TYPE: 
USE: 
PURPOSE 


NAME  : 
TYPE: 
USE: 
PURPOSE 


NAME : 
TYPE: 
USE  : 

PURPOSE 

NAME  : 
TYPE: 
PURPOSE 
CALLS : 
CALLED 

NAME: 
TYPE: 
USE : 
PURPOSE 

NAME  : 
TYPE: 
USE: 
PURPOSE 


ITRNR  (10) 

Local  variable 
Subroutine  WORDS 

:  ASCII  equivalent  of  TURN  RIGHT 

11 

Local  variable 
Subroutine  WORDS 

:  Loop  control  used  in  computing  which  lines  to 

write  MAX  in  the  menu 

IIMJL 

Local  variable 
Subroutine  WORDS 

:  Y-coordinate  in  absolute  units  of  the 

incremental  lines  on  which  to  write  MAX  in  the 
the  menu 

JALI-IJS) 

Local  variable 
Subroutine  FLYAC 

:  ASCII  equivalent  of  ENTER  FEET> 

Prompt  for  pilot  input 

um 

Common  block  name 

Subroutine  GINITL,  INPUT,  ECMWDS,  ECMVAL, 
JAMMER 

:  Data  pertaining  to  Jammers 

Subroutine  name 

:  Responds  to  pilot  menu  pick  of  JAMMER 

BOXER,  REFRSH 
EY:  FLYAC 

Local  variable 
Subroutine  JAMMER 

:  ASCII  equivalent  of  ENTER  JAMMER  #> 

Local  variable 
Subroutine  ECMWDS 
:  ASCII  equivalent  of  JAMMER_ 


I 


NAME:  JMB-iSi 

TYPE:  Local  variable 

USE:  Subroutine  WORDS 

PURPOSE:  ASCII  equivalent  of  ECM  MODE 


I 

r 

i'V 

I 


k' 


NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 
TYPE : 
USE: 

PURPOSE: 

NAME: 
TYPE : 
USE: 

PURPOSE: 

NAME: 
TYPE : 
USE: 

PURPOSE : 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 
TYPE : 
USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 


NAME: 

TYPE: 

USE: 

PURPOSE; 

NAME: 

TYPE; 

USE: 

PURPOSE: 


Local  variable 
Subroutine  JAMMER,  FLYAC 

Whether  normal  or  max  Jammer  mode  was  picked 
ill 

Local  variable 
Subroutine  FLYAC,  JAMMER 
X-coordinate  at  which  to  print  prompt 

ill 

Local  variable 
Subroutine  FLYAC,  JAMMER 
Y-coordinate  at  which  to  print  prompt 

Local  variable 

Subroutine  HITGND 

ASCII  equivalent  of  KABOOM 

Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  CHAFF  LEFT 

miM 

Local  variable 
Subroutine  PLTSIT 

ASCII  equivalent  of  the  symbol  to  be  plotted 


mil 

Local  variable 
Subroutine  ABORT 
Amount  of  change  required 
present  to  abort  parameter 


to  transition  from 


Local  variable 
Subroutine  ECMWDS 

ASCII  equivalent  of  CURRENT  ECM  STATUS 

££LA£E-llli 

Local  variable 

Subroutine  WORDS 

ASCII  equivalent  of  FLARES  LEFT 
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NAM 

TYPE;  Local  variable 

USE:  Subroutine  ECMWDS 

PURPOSE;  ASCII  equivalent  of  FREQ  BAND 

NAME;  Mmia 

TYPE:  Common  variable  (CLOCK) 

USE;  Subroutine  GINITL,  KPTIM,  WRITER 

PURPOSE:  Simulated  hours  into  the  mission 

NAME:  KNOT  (1^) 

TYPE:  Local  variable 

USE:  Subroutine  FLYAC 

PURPOSE:  ASCII  equivalent  of  ENTER  KNOTS> 

Prompt  for  pilot  input 

NAME:  Mfili 

TYPE:  Local  variable 

USE:  Subroutine  FLYAC,  DECEL,  ACCEL 

PURPOSE:  Speed  change  parameter 

NAME;  KQUT 

TYPE;  Local  variable 

USE:  Subroutine  WRITER,  ECMVAL,  WEPVAL,  RUNSIM 

PUTTIM 

PURPOSE:  Character  equivalent  of  a  number 

name: 

TYPE:  Local  variable 

USE;  Subroutine  WEPWDS 

PURPOSE:  ASCII  equivalent  of  _PK_ 


NAME  : 
TYPE; 
USE: 

PURPOSE : 

NAME: 
TYPE : 
USE: 

PURPOSE: 


Local  variable 

Subroutine  ECMWDS 

ASCII  equivalent  of  POWER 


Local  variable 
Subroutine  FLYAC,  GSETUP 
ASCII  equivalent  of  MAKE  INPUTS  NOW 
Prompt  for  pilot  input 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 
Subroutine  FLYAC,  GSETUP 

ASCII  equivalent  of  TYPE  **c"  WHEN  COMPLETE 


NAME: 

TYPE: 

USE: 

CALLS: 
CALLED  BY: 

NAME: 

TYPE: 

USE: 

PURPOSE: 


KfZlM 

Subroutine  naae 

Keeps  time  in  hours,  minutes,  seconds 

None 

RUNSIM 


Local  variable 

Subroutine  WEPWDS 

ASCII  equivalent  of  RF  MISSILES 


NAME:  KSECMD 

TYPE:  Common  variable  (CLOCK) 

USE:  Subroutine  GINITL,  KPTIM,  WRITER 

PURPOSE:  Simulated  seconds  into  the  mission 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 

Subroutine  ECMWDS 

ASCII  equivalent  of  SECTOR 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 

Subroutine  WEPWDS 

ASCII  equivalent  of  SMART  BOMBS 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 
Subroutine  WEAPON 

ASCII  equivalent  of  SELECT  TARGET 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Local  variable 
Subroutine  GETTGT 

ASCII  euqivalent  of  VISUAL  DISPLAY 


NAME:  tCWEP  (5) 

TYPE:  Local  variable 

USE:  Subroutine  WEPWDS 

PURPOSE:  ASCII  equivalent  of  CURRENT  WEAPON  STATUS 


NAME: 

TYPE: 

USE: 

PURPOSE: 


NAME: 

TYPE: 

USE: 

PURPOSE: 


LCOL 

Local  variable 
Subroutine  WORDS 

X-coordlnate  in  absolute  units  of  the  aircraft 
status  key  words 

LEFT 

Local  constant 
Subroutine  TURN,  FLYAC 
Indicates  direction  of  turn 
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NAME: 

TIPE: 

USE: 

PURPOSE: 


Local  variable 

Subroutine  WEPWDS 

ASCII  equivalent  of  #LEFT 


NAME: 
TYPE : 
USE: 

PURPOSE : 


L£ICQL 

Local  variable 
Subroutine  WORDS 

X-coordinate  in  absolute  units  of  the  menu  key 
word  3 


NAME: 

TYPE: 

USE: 

PURPOSE: 


LIIIM 

Common  variable  (STATUS) 

Subroutine  GINITL,  FLYAC,  STATVL 
TRUE  when  aircraft  is  turning  left 


NAME: 

TYPE: 

USE: 

PURPOSE: 


LJtillS 

Common  block  name 
Subroutine  GINITL,  STATVL 
Aircraft  flight  capabilities 


NAME: 

TYPE: 

USE: 

PURPOSE : 


LLX 

Local  variable 
Subroutine  BOXER 

X-coordinate  in  absolute  units  of  the  lower 
left  corner  of  the  desired  box 


NAME: 

TYPE: 

USE: 

PURPOSE: 


LLl 

Local  variable 
Subroutine  BOXER 

Y-coordinate  in  absolute  units  of  the  lower 
left  corner  of  the  desired  box 


NAME: 
TYPE : 
USE: 

PURPOSE : 


Common  block  name 
Subroutine  GINITL,  STATVL 
Position  of  the  aircraft 


NAME: 

TYPE: 

PURPOSE: 


CALLS: 
CALLED  BY: 


LILQU, 

Subroutine  name 

Resets  status  flag  and  fuel  use  rate  to 
simulate  the  aircraft  leveling  off  from  an 
altitude  change 
RSETFF 

ABORT,  CLIMB,  DESCND,  FLYAC,  HITGND,  STATVL 


NAME: 

TYPE: 

USE: 

PURPOSE: 


unAU 

Local  variable 
Subroutine  WORDS 
ASCII  equivalent  of  MAX 
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Common  variable  (ACPRAM) 

Subroutine  FLYAC 

Aircraft  maximum  rate  of  acceleration. 


NAME  : 
TYPE  : 
USE; 

PUR  POSE : 

NAME  ; 
TYPE  : 

USE  : 

PURPOSE: 

NAME  : 
TYPE  : 
USE; 

PUR  POSE : 

NAME  : 
TYPE  : 

USE  : 

PURPOSE  : 

NAME  : 
TYPE  : 

USE  ; 

PUR  POSE : 

NAME  : 
TYPE  : 
USE: 

PURPOSE: 

NAME  : 
TYPE  : 

USE ; 

PURPOSE  : 

NAME: 
TYPE  : 

USE : 

PURPOSE: 

NAME  : 
TYPE  : 

USE  : 

PUR  POSE  : 

NAME  : 
TYPE  : 

USE  : 

PUR  POSE  ; 


Common  variable  (ACPRAM) 

Subroutine  FLYAC,  GIKITL 
Aircraft  maximum  descent  rate 

MAXSLO 

Common  variable  (ACPRAM) 

Subroutine  FLYAC,  GINITL 

Aircraft  maximum  rate  of  deceleration 

Common  variable  (ACPRAM) 

Subroutine  FLYAC,  GINITL 
Aircraft  maximum  rate  of  turn 

Common  variable  (ACPRAM) 

Subroutine  FLYAC,  GINITL 
Aircraft  maximum  rate  of  climb 

MEM 

Common  block  name 

Subroutine  REBOX,  GINITL,  ACCEL,  CLIMB,  DECEL 

DESCND,  LVLOFF,  ROLOUT,  SETSPD,  TURN 

Things  to  remember  when  refreshing  the  screen 

Common  variable  (MEM) 

Subroutine  REBOX,  GINITL,  ACCEL,  CLIME,  DECEL 
DESCND,  LVLOFF,  ROLOUT,  SETSPD,  TURN 
Flags  as  to  which  menu  box  to  highlight 

Him 

Common  variable  (CLOCK) 

Subroutine  GINITL,  KPTIM,  WRITER 
Simulated  minutes  into  the  mission 

Local  variable 
Subroutine  WORDS 

ASCII  euqivalent  of  CURRENT  MISSION  STATUS 

HISTIH 

Common  variable  (SECS) 

Subroutine  GINITL,  STATVL,  WRITER,  PPCCE" 
Elapsed  mission  time 


N  Ah£  : 
riPt : 
PURPOSE 


TEKTRONIX  abroutine 

See  TEKTRONIX  documentation 


N  A  h  E  : 

TYPE: 
PORPOSE : 

TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 

t.  A  M  E  : 

Y  f  E  : 

USE: 

r  c  h  f  L  E  t.  : 

Milt 

Common  variable  (SECS) 

Subroutine  PHOCES,  GINITL 

i  ax  of  .ii". ul  a  t i o r 

USE : 

PURPOSE : 

;  r  t 

r  r  i  ;  L 

■  :  . 

Subroutine  CLIMB,  DESCND,  GINI"’L 

Altitude  to  which  the  aircraft  is  transitioning 

NAME  : 

type  : 

USE: 

PURPOSE : 

Local  variable 

Subroutine  REDY,  AADRIVER 

TRUE  when  user  requests  operation  assistance 

NAME  : 

TYPE : 

USE : 

PURPOSE : 

liiJeLiiM 

Common  variable  (ACSTAT) 

Subroutine  TURN,  ROLOUT,  GINITL 

Heading  to  which  the  aircraft  is  transitioning 

NAME  : 

”YPE: 

PURPOSE: 

HiULLllL 

TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 

NAME: 

TYPE: 

PURPOSE: 

MMEAG 

TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 

NAME  : 

TYPE  : 

USE: 

PURPPOSE : 

Common  variable  (ACSTAT) 

Subroutine  ACCEL,  DECEL,  SETSPD,  GINITL 

Speed  to  which  the  aircraft  is  transitioning 

NAME  : 

TYPE  : 

USE: 

PURPOSE: 

NONE 

Local  variable 

Subroutine  PIKSIT 

ASCII  equivalent  of  NO  SITES  IN  RANGE 

NAME:  NORMDN 

TiPE:  Common  variable  (ACPRAM) 

USE:  Subroutie  FLYAC,  GINITL 

PURPOSE:  Aircraft  normal  descent  rate 

NAME:  NORMUP 

TYPE:  Common  variable  (ACPRAM) 

USE:  Subroutine  FLYAC,  GINITL 

PURPOSE:  Aircraft  normal  rate  of  climb 

NAME:  NRMACC 

TYPE:  Common  variable  (ACPRAM) 

USE:  Subroutine  FLYAC,  GINITL 

PURPOSE:  Aircraft  normal  rate  of  acceleration 

NAME:  MBtlSLO 

TYPE:  Common  variable  (ACPRAM) 

USE:  Subroutine  FLYAC,  GINITL 

PURPOSE:  Aircraft  normal  rate  of  deceleration 

NAME:  MllIM 

TYPE:  Common  variable  (ACPRAM) 

USE:  Subroutine  FLYAC,  GINITL 

PURPOSE:  Aircraft  normal  rate  of  turn 

NAME:  NTRGET 

TYPE:  Common  variable 

USE:  Subroutine  GETTGT 

PURPOSE:  Site  number  of  target  selected  by  "pilot" 

NAME:  NUMCHF 

TYPE:  Common  variable  (WEAPNS) 

USE:  Subroutine  CHAFF,  GINITL,  INPUT 

PURPOSE:  Number  of  pods  of  chaff  available 

NAME:  NUMFLR 

TYPE:  Common  variable  (WEAPNS) 

USE:  Subroutine  FLARE,  GINITL,  INPUT 

PURPOSE:  Number  of  flares  available 

NAME:  MtliM 

TYPE:  Common  variable  (JAMM) 

USE:  Subroutine  GINITL,  INPUT,  ECMWDS 

PURPOSE:  Number  of  Jammers  on  the  aircraft 

NAME:  MUm 

TYPE:  Common  variable  (VISBLE) 

USE:  Subroutine  PIKSIT,  PLTSIT 

PURPOSE:  Number  of  sites  which  are  possible  to  bomb 


NAM 

TIPE:  Local  constant 

USE:  Subroutine  C*IRCLE 

PURPOSE:  Standard  geometric  value  3.1^1592 

NAME:  £imX 

TYPE:  Subroutine  name 

PURPOSE:  Gets  user  pick  of  targets  available 

CALLS:  VCURSR,  NEWPAG,  ANMODE,  HELP,  REFRSH,  PLTSIT, 

CHRSIZ,  TRANGL,  SWINDO,  RROTAT 
CALLED  BY:  GETTGT 


NAME: 

TYPE: 

USE: 

PURPOSE: 


NAME: 

TYPE : 
PURPOSE: 

CALLS : 

CALLED  BY: 

NAME: 

TYPE: 

USE: 

PURPOSE : 

NAME: 

TYPE : 

USE: 

PURPOSE: 

NAME: 

TYPE : 

PURPOSE: 

CALLS: 

CALLED  BY: 


Local  variable 
Subroutine  RWR  PLOT 

Signals  if  site  has  any  live  components  to 
avoid  plotting  dead  sites 


PLTSIT 

Subroutine  name 

Plots  all  threat  sites 

aircraft 

CHRSIZ,  MOVABS,  ANSTR , 
SWINDO,  POINTA,  RROTAT, 
PIKSIT,  GETTGT 


within  visual  rang 

ANMODE,  DWINDO,  Cl 
MOVEA,  POINTR,  ANCHi 


Common  variable  (JAMM) 

Subroutine  GINITL,  INPUT,  ECMVAL,  JAMMER 
Power  setting  of  respective  Jammer 

PQMEBl 

Local  variable 
Subroutine  STRNTH,  RWRPLT 

Power  of  radar  signal  received  at  aircraft 

mLLUl 

Subroutine  name 

Driver  for  all  the  preliminary  tasks 
INITT,  TERM,  WELCUM,  GINITL,  REDY,  NEWPAG, 
INF01,  INF02,  TNF03,  SETDEV,  GSETUP,  WAIT 
AADRIVER 


NAME: 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 


Subroutine  name 

Handles  interupts  and  drives  the  interactive 
simulation 

ENABLE,  FLYAC,  RUNSIM,  REFRSH 
AADRIVER 


HAME;  PUTTIM 

TIPE:  Subroutine  name 

PURPOSE:  Prints  mission  time  in  HR:MIN:SEC  format 

CALLS:  MOVABS,  STRNUM,  ANCHO,  ANMODE 

CALLED  BX:  WRITER 

NAME:  mMi 

TYPE:  Local  variable 

USE:  Subroutine  RWRPLT 

PURPOSE:  Maximum  radar  signal  power  being  received  at 

the  aircraft 

NAME:  MMJiil 

TYPE:  Local  variable 

USE:  Subroutine  PIKSIT,  STATVL 

PURPOSE:  Radian  equivalent  of  aircraft  heading 

NAME:  RADIUS 

TYPE:  Local  variable 

USE:  Subroutine  CIRCLE 

PURPOSE:  Input  parameter/radius  of  the  circle 

NAME:  RATE 

TYPE:  Local  variable 

USE:  Subroutine  ABORT 

PURPOSE:  Real  equivalent  of  rate  of  change  for  required 

maneuvering 

NAME:  BDBBMG 

TYPE:  Local  variable 

USE:  Subroutine  RWRPLT 

PURPOSE;  "Line  of  sight"  of  radar 

NAME; 

TYPE:  Subroutine  name 

PURPOSE:  Rehighlights  menu  boxes  for  which  maneuver  is 

still  active  after  refresh 
CALLS;  BOXER 

CALLED  BY:  REFRSH 

NAME:  REDY 

TYPE;  Subroutine  name 

PURPOSE;  Tells  user  file  input  complete  and  determines 

whether  to  print  user  operation  assistance 
routines 

CALLS;  CHRSIZ,  ANMODE,  NEWPAG 

CALLED  BY:  PRELIM 

NAME: 

TYPE:  Subroutine  name 

PURPOSE:  Controls  the  redrawing  of  the  graphics  display 

CALLS:  NEWPAG,  DISPLA,  WRITER,  REBOX 

CALLED  BY:  FLYAC,  GSETUP.  HITGND,  PIKSIT,  SHAKE,  STALL, 
WEAPON,  JAMMER 


NAME:  RELATE 

TItPE:  Subroutine  name 

PURPOSE:  Interfaces  the  interactive  aircraft  parameters 

with  AADEM  vehicle  #1 
CALLS:  None 

CALLED  Bl:  RUNSIM 

NAME:  RESUME 

TiPE:  Subroutine  name 

PURPOSE:  Responds  to  pilot  menu  pick  of  RESUME  INITIAL 

FLIGHT  PATH 
CALLS:  BOXER 

CALLED  Bl:  FLYAC 


NAME:  RFMSPK 

TYPE:  Common  variable  (WEPPKS) 

USE:  Subroutine  GINITL,  INPUT,  WEAPON 

PURPOSE:  Probability  of  kill  for  an  RF  MISSILE 

NAME:  RLQSS 

TXPE:  Local  variable 

USE:  Subroutine  STRNTH 

PURPOSE:  Loss  factor  for  radar  signal 

NAME:  ROLQUT 

TIPE:  Subroutine  name 

PURPOSE:  Resets  status  flag  to  indicate  constant  heading 

and  resets  the  fuel  use  rate  accordingly 
CALLS:  RSETFF 

CALLED  BY:  ABORT,  FLYAC,  STATVL,  TURN 

NAME:  Mmi 

TYPE:  TEKTRONIX  subroutine 

PURPOSE:  See  TEKTRONIX  documentation 

NAME:  RSETFF 

TYPE:  Subroutine  name 

PURPOSE:  Adjusts  aircraft  fuel  use  rate  at  completion  of 

a  flight  maneuver 
CALLS:  NONE 

CALLED  BY:  ROLOUT,  LVLOFF,  SETSPD 

NAME:  RTING 

TYPE:  Common  variable  (STATUS) 

USE:  Subroutine  GINITL,  FLYAC,  STATVL 

PURPOSE:  TRUE  when  aircraft  is  turning  right 
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NAME: 

TYPE 

PURPOSE: 


CALLS  : 
CALLED  BY: 


Subroutine  name 

Updates  all  parameters  of  the  simulation  to 
reflect  the  time  increment  fed  as  an  input 
argument  then  refreshes  the  screen  to  feed  this 
information  to  the  user 

STATVL,  VIEWS,  RADPAR,  RADSIG,  JAMSIG,  JTSCOM , 

BATTLE2,  KPTIM 

PROCES 


NAME  : 

TYPE: 
PURPOSE : 
CALLS: 
CALLED  BY: 


Subroutine  name 
Draws  the  RWR 

MOVABS,  ANSTR,  SWINDO,  CIRCLE,  TRANGL 
DISPLA 


NAME  : 

TYPE: 
PURPOSE: 
CALLS : 

CALLED  BY: 


RWRPLT 

Subroutine  name 

Plots  the  sites  for  the  RWR  display 

CHRSIZ,  MOVABS,  ANMODE,  DWINDO,  SWINDO  RROTAT, 

STRNTH,  MOVEA,  POINTR 

RWR 


NAME: 

TYPE: 

USE: 

PURPOSE: 


Common  variable  (WEPPKS) 

Subroutine  GINITL,  INPUT,  WEAPON 
Probability  of  kill  for  a  smart  bomb 


NAME: 


TYPE: 

Common  block  name 

USE: 

Subroutine  GINITL,  SI 

PURPOSE : 

Elapsed  mission  time, 

NAME: 

TYPE: 

Subroutine  name 

PURPOSE: 

Establish  cursor  home 

CALLS: 

None 

CALLED  BY: 

PRELIM 

NAME: 

SETFF 

TYPE: 

Subroutine  name 

PURPOSE: 

Adjusts  aircraft  f 
flight  maneuver 

CALLS: 

None 

CALLED  BY: 

ACCEL,  CLIMB,  DECEL, 

NAME: 

TYPE: 

Subroutine  name 

PURPOSE: 

Resets  status  flat 

fuel  use  rate  to  begin 


DESCND,  TURN,  WEAPON 


and 


simulate  the  aircraft 
from  an  acceleration  or 
RSETFF 

ABORT,  ACCEL,  DECEL, 
STATVL 


fuel  use 
stabilizing 
deceleration 


rate  to 
its  speed 


FLYAC,  SHAKE,  STALL, 


CALLS: 
CALLED  BY 


"iPE:  Subroutine  name 

PURPOSE:  Handles  functions  if  the  pilot  attempts  to 

exceed  the  aircraft’s  maximum  speed 
CALLS:  ANMODE,  REFRSH,  BOXER,  WAIT,  ANCHO,  SETSPD 

CALLED  BY:  STATVL 

NAME:  iim 

TYPE:  Local  variable 

USE:  Subroutine  CIRCLE 

PURPOSE:  Sine  of  THETA 

NAME:  SLOADJ 

TYPE:  Common  variable  (FUELS) 

USE:  Subroutine  DECEL,  SETSPD,  GINITL 

PURPOSE:  Fuel  use  rate  adjustment  for  deceleration 

NAME: 

TYPE:  Common  variable  (STATUS) 

USE:  Subroutine  GINITL,  FLYAC,  STATVL 

PURPOSE:  TRUE  when  aircraft  is  decelerating 

NAME: 

TYPE:  Common  variable  (FLPRAM) 

USE:  Subroutine  DECEL 

PURPOSE:  Fuel  use  rate  adjustment  for  a  maximum  rate 

deceleration 

NAME:  SLflUflU 

TYPE:  Common  variable  (FLPRAM) 

USE:  Subroutine  DECEL 

PURPOSE:  Fuel  use  rate  adjustment  for  a  normal  rate 

deceleration 

NAME:  SLORAT 

TYPE:  Local  variable 

USE:  Subroutine  FLYAC,  DECEL 

PURPOSE:  Deceleration  rate  parameter 

NAME:  SLOW 

TYPE:  Local  variable 

USE:  Subroutine  DECEL 

PURPOSE:  FLAG  to  SETSPD  to  indicate  stabilize  speed  from 

deceleration 


NAME:  SPEED 

TYPE:  Common  variable  (ACSTAT) 

USE:  Subroutine  ACCEL,  DECEL,  SETSPD,  GINITL 

PURPOSE:  Current  aircraft  airspeed 


NAME  : 

TYPE; 

PURPOSE: 

CALLS: 

CALLED  BY: 

NAME; 

TYPE: 

USE; 

PURPOSE: 


NAME : 

TYPE  : 
PURPOSE: 
CALLS: 
CALLED  BY; 

NAME  : 

TYPE: 

USE: 

PURPOSE: 


NAME: 

TYPE: 

USE: 

PURPOSE : 

NAME : 

TYPE; 

PURPOSE: 

CALLS: 
CALLED  BY: 

NAME: 

TYPE; 

PURPOSE; 

NAME: 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY: 

NAME  : 

TYPE: 

PURPOSE; 


S:£LL 

Subroutine  name 

Handles  functions  if  the  pilot  attempts  to  fly 
slower  than  the  aircraft's  minimum  speed 
REFRSH,  BOXER,  ANMODE,  WAIT,  ANCHO,  HITGND, 
SETSPD 
STATVL 

STATUS 

Common  block  name 

Subroutine  GINITL,  FLYAC,  ABORT,  LVLOFF, 
SETSPD,  ROLOUT 

Flags  which  indicate  the  transient  states  of 
the  aircraft 

Subroutine  name 

Computes  the  current  mission  status  values 
LVOFF,  HITGND,  SHAKE,  SETSPD,  STALL,  ROLOUT 
RUNSIM 

SI££SZ 

Local  constant 
Subroutine  CIRCLE 

Roundness  factor  for  the  circle  drawing 
algorithm 

SILSffi 

Common  variable  (LIMITS) 

Subroutine  GINITL,  STATVL 

Slowest  speed  the  aircraft  can  attain 

Subroutine  name 

Determines  the  power  of  a  radar  signal  at  the 

aircraft 

None 

RWRPLT 

mium 

TEKTRONIX  subroutine 

See  "AFWAL  Auxiliary  PLOT-10  Routines" 

STRTSM 

Subroutine  name 

Alows  user  inputs,  then  starts  time  for 

simulation 

FLYAC 

AADRIVER 

SWINDO 

TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 
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TiPE: 

PURPOSE 


TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 


NAME: 

TXPE: 

USE: 

PURPOSE: 


IMIA 

Local  variable 
Subroutine  CIRCLE 
Arc  of  the  circle 


NAME  : 
TYPE: 

USE : 

PURPOSE: 


Common  variable  (LIMITS) 

Subroutine  GINITL,  STATVL 

Fastest  speed  the  aircraft  can  attain 


NAME: 

TYPE: 
PURPOSE : 

CALLS: 
CALLED  BY: 


Subroutine  name 

Draws  a  triangle  around  the  present  cursor 

position 

MOVER,  DRAWR 

PIKSIT,  RWR 


NAME  : 
TYPE: 
USE: 

PURPOSE  : 


IMAM 

Common  variable  (FUELS) 

Subroutine  TURN,  ROLOUT,  GINITL 
Fuel  use  rate  adjustment  for  turning 


NAME: 

TYPE: 

USE: 

PURPOSE: 


IMHAl 

Common  variable  (FLPRAM) 

Subroutine  TURN,  GINITL 

Fuel  use  rate  adjustment  for  a  maximum  rate 
turn 


NAME: 

TYPE; 

USE: 

PURPOSE ; 


IMILM 

Common  variable  (FLPRAM) 

Subroutine  TURN,  GINITL 

Fuel  use  rate  adjustment  for  a  normal  rate  turn 


NAME : 
TYPE: 
USE: 

PURPOSE; 


IMMI 

Local  variable 
Subroutine  FLYAC,  TURN 
Turn  rate  parameter 


NAME: 

TYPE; 

USE: 

PURPOSE: 


Common  block  name 

Subroutine  INPUT,  GINITL,  PROCES,  FLYAC 
Simulation  timing  parameters 


NAME: 

TYPE: 

PURPOSE: 

CALLS : 
CALLED  BY: 


TURN 

Subroutine  name 

Simulates  pilot  actions  to  cause  the  aircraft 
to  turn 

SETFF,  BOXER,  ROLOUT 
ABORT,  FLYAC 


NAM 
TYPE: 
USE: 

PURPOSE; 

NAME: 
TYPE  : 
USE: 

PURPOSE; 

NAME  : 
TYPE  : 
USE: 

PURPOSE; 


NAME  : 
TYPE : 
USE: 

PURPOSE; 


NAME: 

TYPE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 

TYPE: 

USE: 

PURPOSE: 

NAME: 

TYPE: 

PURPOSE: 

CALLS: 
CALLED  BY 

NAME: 

TYPE: 

USE: 

PURPOSE: 


Common  variable  (FUELS) 

Subroutine  CLIMB,  LVLOFF,  GINITL 
Fuel  use  rate  adjustment  for  a  climb 

mM 

Common  variable  (STATUS) 

Subroutine  GINITL,  FLYAC,  STATVL 
TRUE  when  aircraft  is  climbing 

Local  variable 
Subroutine  CLIMB 

Fuel  use  rate  adjustment  for  a  maximum  rate 
climb 

Common  variable  (FLPRAM) 

Subroutine  CLIMB 

Fuel  use  rate  adjustment  for  a  normal  rate 
climb 

TEKTRONIX  subroutine 

See  TEKTRONIX  documentation 

rnstm 

Local  variable 
Subroutine  PLTSIT 

Radius  of  visibility  of  pilot  from  altitude 


COMMON  variable  (VISBLE) 

Subroutine  PLTSIT,  PIKSIT 
Data  about  visible  sites 

WAIT 

Subroutine  name 

Delays  processing  to  synchronize  simulated  time 
with  real  time 
SYS$SETIMR,  SYS$WAITFR 
HITGND,  SHAKE,  STALL,  PRELIM 


Common  variable  (TSTEP) 

Subroutine  GINITL,  RUNSIM 
Multiplier  for  the  WAIT  function 

Accelerate  or  decelerate  the  "real  time"  aspect 
of  the  simulation 


NAME : 

WEAP 

TYPE: 

Common  logical  variable  (DISP) 

USE: 

Subroutine  REFRSH,  DISPLA,  WRITER,  GINITL, 
FLYAC,  GSETUP,  SHAKE,  STALL,  WEAPON,  PIKSIT, 
JAMMER 

PURPOSE: 

TRUE  when  the  CURRENT  WEAPON  STATUS  block  and 
Visual  Display  are  to  be  presented 

NAME : 

TYPE: 

Common  block  name 

USE: 

Subroutines  CHAFF,  FLARE 

PURPOSE: 

All  common  information  relating  to  weapons 

NAME: 

TYPE: 

Subroutine  name 

PURPOSE: 

Responds  to  pilot  menu  pick  of  WEAPON 

CALLS: 

REFRSH,  GETTGT,  ANSTR,  ANMODE,  NEWLIN,  SETFF , 
BOXER,  TARGET 

CALLED  BY: 

FLYAC 

NAME: 

TYPE: 

Subroutine  name 

PURPOSE: 

Prints  introductory  message  to  amuse  user  while 
files  are  input 

CALLS: 

CHRSIZ,  ANMODE 

CALLED  BY: 

PRELIM 

NAME: 

MfiCeKS 

TYPE: 

Common  block  name 

USE: 

Subroutine  GINITL,  INPUT,  WEAPON 

PURPOSE: 

Probability  of  kills  for  the  weapons 

NAME: 

iimAL 

TYPE: 

Subroutine  name 

PURPOSE: 

Writes  the  values  for  the  CURRENT  WEAPON  STATUS 
block 

CALLS: 

CHRSIZ,  MOVABS,  STRNUM  ANSTR 

CALLED  BY: 

WRITER 

NAME: 

MfigMDS 

TYPE: 

Subroutine  name 

PURPOSE: 

Writes  the  weapon  information  for  the  CURRENT 
WEAPON  STATUS  block 

CALLS: 

MOVABS,  ANSTR 

CALLED  BY: 

WORDS 

NAME: 

BOBCS 

TYPE: 

Subroutine  name 

PURPOSE: 

Lays  out  the  key  words  for  the  static  part  of 
the  output  display 

CALLS: 

CHRSIZ,  MOVABS,  ANCHO,  ANSTR,  ECMWDS,  WEPWDS 

CALLED  BY: 

DISPLA 
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NAME: 

MUM 

TYPE: 

Subroutine  name 

PURPOSE: 

Writes  all  dynamic  values  in  the 
rectangles  of  the  interactive  display 

lower 

CALLS: 

CHRSIZ,  STRNUM,  MOVABS,  ANSTR,  ECMVAL, 
PUTTIM 

WEPVAL, 

CALLED  BY: 

REFRSH 

NAME  : 

XDIS 

TYPE: 

Local  variable 

USE: 

Subroutine  PIKSIT,  PLTSIT,  RWRPLT 

PURPOSE: 

X  coordinate  distance  from  aircraft  to 
from  cursor  to  site 

site  or 

NAME: 

XPBIME 

TYPE: 

Local  variable 

USE: 

Subroutine  PIKSIT 

PURPOSE: 

Transformed  x  coordinate  from  VCURSR 

NAME: 

MI 

TYPE: 

Local  variable 

USE: 

Subroutine  RWRPLT 

PURPOSE: 

X  coordinate  of  point  to  be  plotted 

NAME: 

XSEC 

TYPE: 

Local  variable 

USE: 

Subroutine  STRNTH 

PURPOSE: 

Radar  cross  section  of  aircraft 

NAME: 

xm 

TYPE: 

Local  variable 

USE: 

Subroutine  PIKSIT,  PLTSIT,  RWRPLT 

PURPOSE: 

Y  coordinate  distance  from  aircraft  to 
from  cursor  to  site 

site  or 

NAME: 

TYPE: 

Local  variable 

USE: 

Subroutine  PIKSIT 

PURPOSE: 

Transformed  Y  coordinate  from  VCURSR 

NAME: 

YPT 

TYPE: 

Local  variable 

USE: 

Subroutine  RWRPLT 

PURPOSE: 

Y  coordinate  of  point  to  be  plotted 

Foreword 


The  FI  RAG  E  software  is  an  interactive  operation  of 
the  AADEM  model  jsed  in  the  Avionics  Laboratory  at  V'rirht 
Patterson,  Air  Force  Ease.  It  allows  vehicle  one  of  the 
AADEM  model  to  be  interactively  "flown"  throusrh  the 
pre-programmed  defensive  network.  It  is  basically  the 
simulation  of  a  "wild  weasel"  type  aircraft  attempting  to 
penetrate  enemy  defensive  systems  and  destroy  preplanned 


targets . 

MIRAGE  allows  for  alterin 

g  direction. 

speed  ,  and 

altitude 

,  deploying 

wea pons  ,  and 

using  radar 

and 

radar 

j  amm ing 

equipment  . 

The  user  is 

graphically 

shown 

his 

current  environment  as  available  through  the  use  of  radar 
equipment,  or  by  looking  out  the  aircraft  windows.  All 
other  information  genet*  ally  available  to  a  pilot  is 
available  in  the  various  displays. 


T?ble  of  Contents 


I  n  t  r  o(^  uc  t  i  on  . . . 

Pre -Sim ul? t ion  . 

Displpys  . 

Configuninp:  the  /'ircraft . 

Cperatini?  the  Simulation  .  .  .  .  .  .  . 
Interpnetinr  the  Displays  .  .  .  . 
Interacting  with  the  Simulation 
Control  Characters  . 


This  guide  describes  all  user  ections  and  displays 
involved  in  the  operation  of  the  KTRAGF  softv;are.  The  tvo 
parts  of  this  guide  correspond  to  the  two  phases  of 
execution:  pre-simulation  and  simulation.  It  chrono¬ 
logically  discusses  the  execution  of  the  t'lRAGE  system. 

During  the  initial,  or  pre-simulat ion  phase,  the  user 
is  shown  orientation  and  information  displays  and  is  given 
the  opportunity  to  configure  the  aircraft  specifically  for 
the  given  mission. 

The  second,  or  simulation  phase  is  menu-driven  and 
uses  the  crosshair  capacity  of  the  TEKTRONIX  *^016  terminal 
to  pick  the  menu  items,  and  some  keyboard  inputs  to  further 
define  user  desires.  This  guide  includes  sample  displays 
from  the  r-'IRAGE  execution  which  are  fully  explained. 

The  user  should  be  familiar  with  this  guide  before 
attempting  to  operate  the  simulation.  Anyone  familiar  with 
this  guide  will  find  the  interface  fairly  'friendly',  and 
before  long  will  be  "flying"  like  an  ace. 

Any  items  marked  V'ith  an  asterisk  (•)  in  the  second 
section,  "Operating  the  Simulation"  have  not  been 
completely  implemented. 


After  execution  of  the  proprem  is  inititeted,  e 
welcome  display  v;ill  be  presented  on  the  screen.  This 
display  has  two  purposes.  First,  it  lets  you  know  that  you 
have  successfully  accessed  the  model.  Second,  it  Fives  you 
somethinr  to  look  at  while  the  AADEM  files  are  beinF  read, 
and  the  propram  variables  are  being  initiali7ed.  Pe 
patient  --  no  action  on  your  part  is  reouired  to  advance 
the  program,  and  no  action  will  expedite  it  either!  When 
the  MIRAGE  system  is  ready  to  work  for  you,  it  will  say 
exactly  that  . 

All  of  your  required  actions  will  be  prompted,  so  you 
need  only  follow  directions.  The  software  will  ask  if  you 
need  instructions  on  how  to  operate  the  simulation.  If  you 
respond  other  than  yes,  the  program  skips  to  the  aircraft 
configuration  routines. 

If  you  respond  yes,  the  first  display  presents  all 
performance  characteristics  for  the  aircraft  being 
simulated.  It  includes  the  maximum  flyinv  speed,  stall 
recovery  altitude  requirements,  and  normal  and  maximum 
rates  for  each  of  the  follow'inp  parameters: 

A )  Fuel  use 

P )  T  urr 

C)  Acceleration 


D )  Deceleration 


E)  Climb 


F)  Descent 

A  photocopy  of  this  information  is  ajtomatically  made  (if 
the  device  is  turned  on)  since  that  is  ouite  a  bit  to 
remember.  When  you  respond  that  you  are  ready  to  continue, 
the  next  display,  which  discusses  ECM  and  weapon  capability 
of  the  aircraft,  is  presented. 

The  simulated  aircraft  can  be  loaded  beyond  the 
capability  of  any  real  aircraft.  It  can  carry  up  to  five 
electro-magnetic  jammers,  any  number  of  iron  bombs,  smart 
bombs,  FF  missiles,  IF  missiles,  chaff  pods,  and  flares. 
Also,  for  each  of  the  weapon  and  ECM  items,  the  probability 
of  kill  (PK)  or  PK  degrade  factor  can  be  anything  from  7ero 
to  one.  This  is  certainly  an  impressive  weapon  platform, 
but  remember  that  the  validity  and  usefulness  of  the 
mission  results  depend  on  your  realistic  selection  of 
aircraft  payload. 

You  will  later  be  offered  the  option  to  change  the 
built  in  timestep  of  twenty  seconds  which  controls  the 
time-advance  of  the  simulation.  Because  the  TEKTPONIX 
terminal  must  be  completely  cleared  and  redrawn  anytime 
something  in  the  display  mu.st  be  changed,  the  information 
on  the  screen  can  never  be  absolutely  current,  The 
clearing  and  redrawing  of  the  screen  takes  slightly  less 
than  one  second.  These  factors  force  you  to  make  a 
compromise  decision.  If  you  select  a  small  timestep  of  two 
or  three  seconds,  in  order  to  have  fairly  current  data 
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displayed,  the  screen  will  be  flashinp  end  drpvinp  so  often 
that  you  probably  won't  be  able  to  read  and  absorb  much 
usable  information.  Cn  the  other  hand,  while  a  lonmer 
timestep  allows  ample  time  to  study  the  display,  plenty  car 
happen  "behind  the  scenes"  that  you  may  not  realize  until 
it  is  too  late  to  respond.  The  default  timestep  is  twenty 
seconds.  For  reference,  at  typical  cruising  airspeeds, 
this  will  usually  be  between  two  and  three  miles  of  ground 
distance.  Since  the  timestep  can  be  changed  anytime  during 
the  simulation  phase,  until  you  gain  experience  with  the 
displays,  I  recommend  you  not  change  it  until  in  the  "run" 
mode  of  the  simulation. 

iour  final  option  is  to  change  the  "delay 
multiplier."  MIRAGE  is  designed  to  run  approximately 
synchronized  to  clock  time,  as  discussed  above,  by  use  of  a 
delaying  function.  The  real  time  aspect  can  be  accelerated 
or  decelerated  by  adjusting  the  delay  multiplier,  v;hich  has 
default  value  of  1.  Setting  the  delay  multiplier  to  .5  for 
example  will  accelerate  the  simulation  in  the  sense  that 
the  delay  between  refreshes  will  be  half  the  timestep,  but 
all  parameters  will  still  be  adjusted  by  the  full  timestep. 
Likewise,  setting  the  multiplier  to  2  will  decelerate  the 
simulation  to  approximately  double  real  time.  An  example 
of  use  for  a  multiplier  less  than  one  is  where  you  know  you 
are  a  long  way  from  the  enemy  sites  and  want  to  get  to 
whene  the  action  is  in  a  hurry.  A  larce  timestep  coupled 
to  a  small  multiplier  will  get  you  across  the  territory  in 


a  hurry. 


Conversely,  if  you  are  in  the  midst  of  the 


action,  and  want  to  watch  things  develop,  your  choice 
should  be  a  small  timestep  and  a  large  multiplier.  The 
delay  multiplier,  like  the  timestep  can  be  changed  during 
kIRAGE  execution,  so  until  you  gain  experience  with  the 
normal  operation  of  the  model,  I  recommend  you  not  change 
it  . 

C.SiUllf.ijrinf: 

The  next  p r e - s i m ul a t i on  function  is  the  actual 
configuring  of  the  aircraft  to  your  specifications.  If  you 
follow  the  prompts,  you  can't  go  wrong.  (If  you  don't 
follow  the  prompts,  the  software  will  tell  you  how  you 
erred,  and  ask  you  to  re-enter  your  parameter.)  There  is  a 


default  value 

for 

the  number 

of 

pieces 

of  each 

type  of 

equipment  and 

the 

associated 

PK 

factor  , 

as  well 

as  the 

timestep  and 

delay 

multiplier , 

so 

if  you 

desire  the  normal 

configuration,  simply  respond  as  such  when  asked. 

The  final  pre-simulation  presentation  reviews  the  run 
time  displays  and  the  control  characters  that  are  used  to 
operate  the  simulation.  I  won't  go  into  detail  about  it 
here,  since  it  is  a  condensation  of  the  materiel  found  in 
the  next  section  of  this  guide. 


The  tvo  displays  available  vrhile  operating  the  KIPPCE 
software  correspond  to  an  offensive  and  defensive  attitude 
of  the  user.  In  both  cases,  the  display  is  made  up  of  five 
sections.  (Refer  to  figure  A- 1  and  figure  A-2  as  needed.) 
The  upper  left  section  of  both  displays  is  the  interactive 
scratch  pad.  If  the  software  reouires  an  input,  it  will 
prompt  you  for  it  in  this  box.  Your  responses  to  the 
prompts  will  also  be  echoed  here. 

The  lower  left  section  of  the  display  contains  the 
CURRENT  RiISSION  STATUS  box.  Here  you  will  find  the  typical 
navigation  and  performance  equipment  readinrs  available  to 
a  pilot .  These  are : 

A)  Elapsed  time  since  the  beginning  of  the 
simulation  (does  not  include  "timeouts"  for  user 
inputs  as  discussed  below) 

P)  True  heading  (Korth=000,  South=l80,  etc.) 

C)  Altitude  in  feet  above  ground  level  (AGL) 

D)  Ground  speed  in  nautical  miles  (6,062.2  feet)  per 
hour 

E)  Fuel  remaining  in  pounds 

F)  Fuel  flow  (burn  rate)  in  pounds  per  hour 

G)  Position  (latitude  and  longitude*) 

The  second  column  in  this  box  displays  the  preplanned 
mission  parameters  for  the  same  elements  discussed  above.* 
This  structure  simulates  the  pilot's  ability  to  compare  his 
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navigation  instruments  to  his  charts  and  flight  rlf’n 
correct  accordingly. 

The  upper  right  section  of  the  display  is  the 

interactive  menu.  It  consists  of  ten  items  for  selection, 
divided  in  some  cases  into  tv;o  columns.  V'ith  this  menu, 
you  control  all  aircraft  maneuvers.  The  top  six  elements 
correspond  to  the  pilot  using  the  ailerons,  elevato’^s, 
rudder,  and  throttle(s)  to  fly  the  aircraft.  The  tvo 
columns  represent  rate  of  m.  ovement  in  the  selected 
direction.  The  left  column  represents  normal  rate,  the 
right  column  maximum  rate.  Recall  that  from  the 
pr e- s im ul a t i on  display,  if  you  had  requested  the 
information,  you  were  furnished  vrith  the  values  for  these 
rates  for  your  aircraft.  The  ECM  MODE  box  also  has  tvo 

columns.  Picking  this  level  will  cause  the  displays  to 

shift  to  the  defensive  mode  which  will  be  discussed  later, 
and  allow  for  adjusting  the  jammers,  deploying  chaff,  or 
deploying  flares.  The  MAX  column  sets  the  "max  confuser" 
mode  for  the  Jamming  equipment.  Picking  the  POMEING  MODE 
box  will  cause  the  displays  to  shift  to  the  offensive  mode 
which  will  be  discussed  below,  and  allows  for  selecting 
targets  and  deploying  weapons.  Selecting  the  RESUME 
PREPLANNED  FLIGHT  PATH  box  will  cause  the  aircraft  to 
return  to  its  preplanned  route  of  flight.*  Selecting  the 
ABORT  box  causes  the  aircraft  to  maneuver,  using  normal 

rates,  to  its  abort  heading,  altitude,  and  airspeed.  This 
simulates  the  pilot's  initial  inputs  to  depart  the  enemy 


territory , 


It  does  not  hamper  the  pilot's  ability  to  make 


other  inputs  in  any  vay. 

The  three  sections  described  above  are  drawn  every 
time  the  screen  is  refreshed.  Which  of  the  following  two 
pairs  of  sections  is  also  drawn  depends  on  whether  the  last 
menu  pick  was  ECM  MODE  or  BOMBING  MODE. 

The  Visual  Display  and  CURRENT  WEAPON  STATUS  box  (see 
figure  A-2)  will  be  draw’n  whenever  BOMBING  MODE  is  picked, 
and  every  refresh  cycle  thereafter  until  the  ECM  MODE  (or 
MAX)  is  selected.  The  weapon  status  box  in  the  lov;er  right 
section  of  the  display,  lists  the  available  weapons  on 
board  by  name  v;ith  a  corresponding  "key",  the  number  of 
that  weapon  type  remaining,  and  the  probability  of  kill  for 
that  weapon  type.  When  the  supply  of  a  weapon  type  is 
exhausted,  the  name  and  other  data  are  removed  from  the 
list.  Similar  information  for  chaff  and  flares  is  shown 
below  the  weapons,  however  chaff  and  flare  information  is 
also  displayed  with  the  ECM  status  which  will  be  discussed 
shortly.  When  in  the  BOMBING  or  offensive  mode,  a  visual 


display  will  appear  in 

the  upper  center 

of 

the 

display . 

The  upper  left  of  this 

d isplay 

shows  the 

visual 

range  in 

meters  indicated  by  the  outer 

circle . 

The 

di 

splay  is 

oriented  to  the  present 

aircraft 

head  ing  , 

so  that 

the  top 

of  the  display  is  the  front  of  the  aircraft;  consider  it  a 
top  viev?  of  your  environment  with  your  aircraft  in  the 


center  . 


There  are  four  symbols  used  on  this  display: 

A)  A  "o"  indicates  that  the  object  is  too  far  away 

to  distinguish 

E)  A  indicates  a  destroyed  site 

C)  A  "/"  indicates  a  AAA  site 

D)  A  indicates  a  ?AM  site 

From  higher  altitudes,  your  visual  range  can  exceed  IOC 
miles,  so  it  would  be  unrealistic  to  allow  you  to  bomb 
anything  in  sight.  However,  it  is  equally  unrealistic  to 
force  you  to  fly  the  simulator  to  the  accuracy  expected  of 
our  bomber  pilots.  To  compromise,  when  visual  range 
exceeds  approximately  seven  miles,  a  smaller  circle  will 
appear  on  the  visual  display.  This  circle  represents  which 
of  the  displayed  sites  you  will  be  allowed  to  bomb  from 
your  present  position.  You  might  want  to  think  of  it  as 
the  eyepiece  of  a  bombsight.  If  only  one  circle  is 
displayed,  any  sites  visible  may  be  bombed. 

When  the  ECh:'  MODE  or  its  FAX  box  are  picked,  the 
CURRENT  ECK  STATUS  and  RADAR  WARNING  RECEIVER  display  are 
drawn.  The  ECM  status  box  shows  the  identification 
character  for  each  jammer,  the  code  number  for  its 
frequency  band,  the  center  of  the  sector  selected  in 
degrees  (i.e.  000  for  North,  090  for  East,  etc.)  and  the 
code  number  for  the  power.  Note  that  ''  displayed  for  the 
power  indicates  that  the  jammer  is  off. 

The  other  defensive  mode  display  is  the  RADAR  WARNING 
RECEIVER  (RWR).  Similar  to  the  Visual  Display,  in  the 


upper  left  hand  section  the  radar  range  is  shovm,  This, 
like  the  visual  rang'=>  factor  is  the  iraximum  possible  frorr 
the  given  altitude.  It  does  not  consider  terrain  or  other 
obstructions.  A  n v  site  emitting  a  radar  pulse  which  is 
received  at  the  aircraft  is  displayed.  Contrast  this  with 
the  visual  display  which  only  shows  threats.  I’ead  Quarters, 
army  field  units,  etc.  may  show  up  on  the  BV.'R  if  they  are 
monitoring  the  aircraft  with  their  radar,  but  unless  there 
is  SAK  or  AAA  equipment  at  that  location,  they  will  not  be 
on  the  visual  display.  On  the  FWF,  all  signals  are  plotted 
with  the  same  symbol.  However,  the  strongest  signal 
received  is  plotted  on  the  outer  circle.  Let  me  say  that 
again:  The  strongest  signal,  possibly  the  closest  site  to 
the  aircraft,  is  plotted  farthest  away  from  the  triangle 
representing  the  aircraft  in  the  center.  This  is 
representative  of  Fadar  Warring  Receivers  being  used  in 
actual  Air  Force  aircraft  today.  It  gives  very  good 
relative  bearing  (azimuth)  information  since  aircraft 
heading  is  considered  to  be  at  the  top,  and  it  prevents  the 
sites  of  importance  (the  strong  signals)  from  hiding  each 
other,  which  would  happen  if  they  were  all  plotted  in  the 
center  of  the  display. 

One  final  note.  V/hen  the  PV'R  display  is  shown,  there 
are  two  "buttons"  which  are  active.  To  the  left  is  the  "C" 
or  chaff  button,  and  to  the  right,  the  "F"  button.  These 
buttons,  as  well  as  how  to  interact  with  the  rest  of  the 
simulation  controls  will  be  explained  in  the  next  section. 


approximately  real  time,  when  it 


9 


running,  and  in  a  "time 


out"  state 

while 

you  are 

making 

inputs  . 

Obviously, 

the 

crucial  th 

i  n  g  E  to 

know  are 

how  to 

stop  it 

so  that  you 

can 

interact , 

and  how 

to  start 

it  aga 

in  when 

your  inputs 

are 

c om  pi  e  te  . 

To  stop 

the  simulation , 

enter  a 

control  c . 

That 

is  ,  hold 

the  'CTRL'  key 

down 

and  type 

a  "c". 

The 

simulation  Kill  stop,  and  the  TEKTRONIX  cursor  will  appear. 
(The  TEKTRONIX  cursor  consists  of  a  very  fine  line 
horizontally  and  vertically  through  the  entire  display.) 
If  you  don't  see  the  cursor,  rotate  the  white  thumb  wheels 
which  are  to  the  right  of  the  keyboard  until  they  appear. 
The  menu  item  for  a  maneuver  is  "picked"  by  positioning  the 
cursor  intersection  in  the  appropriate  box  and  pressing  the 
space  bar.  If  the  software  needs  more  information,  it 
prompts  you  for  it  in  the  interactive  area.  V'hen  all 
requirements  for  the  maneuver  are  complete,  the  cursor  will 
again  appear.  This  allows  you  to  make  as  many  inputs  as 
you  desire  before  restarting  the  simulation.  When  you  have 
entered  all  of  the  maneuvers  you  have  in  mind  for  the 
"timeout"  period,  simply  enter  a  lover  case  "c"  to 
continue.  This  is  also  how  you  initially  start  the 
simulation.  That  is  all  there  is  to  it.  First  let's  look 
at  an  example,  and  then  some  special  cases. 

You  are  cruising  along  at  15,000  feet,  and  decide 


that  you  would  see 


lot  better  f^om  lower  altitude,  and  at 


the  E?mc  time  hide  from  some  of  the  enemy  radar.  First, 
you  have  to  stop  the  simulation  so  that  you  can  interact. 
Hold  the  "CTRL”  key  and  enter  a  "c".  The  cursor  should  now 
be  visible  on  the  screen  (it's  not  very  brif^ht).  If  you 
can't  find  it,  rotate  the  thumb  wheels  a  bit.  Kow  that  you 
have  the  cursor  in  sight,  you  must  decide  which  rate  of 
descent  you  want  to  make.  Remember  the  left  column  is 
normal,  the  rivht  column  maximum  rate  in  the  menu.  How, 
rotate  the  thumb  wheels  to  position  the  cursor  on  your  menu 
choice  and  tap  the  space  bar.  You  have  now  told  the 
software  to  descend,  but  now  you  must  specify  hov'  far.  The 
program  will  prompt  you  with  ENTER  FEET>.  Type  the  number 
of  feet  you  wish  to  descend,  and  a  "return"  key  to  enter 
your  choice.  The  menu  should  display  a  dashed  box  around 
your  menu  pick  to  show  you  that  it  understands  your 
commmand  ,  and  the  cursor  will  return  to  indicate  that  the 
computer  is  ready  for  the  next  commard.  Let  me  repeat  an 
important  point.  When  maneuvering  the  aircraft,  the 
prompts  arc  for  the  change  desired  not  the  destination.  So 
it's  knots  to  change,  not  final  airspeed,  degrees  to  turn, 
rot  new  heading,  etc. 


The  top 

six 

of  the  ten  menu 

items  work 

as  outlined 

above.  Pick 

with 

the  cursor  and 

space  bar , 

then  refine 

your  command 

with 

keyboard  inputs 

by  respond 

i  n  g  to  the 

prompts  in  the  interactive  area. 

Selecting  the  ECK  FCDE  or  its  Fax  box  is  slightly 
different  from  the  above.  First,  the  screen  will  refresh 


I2C 


to  display  the  defensive  mode:  RADAR  WARNING  RECEIVER  and 
CURRENT  ECM  STATUS.  You  will  then  be  prompted  to  enter  the 
jemmer  identifier,  and  the  power  desired.  If  you  enter  zero 
for  power,  you  have  turned  that  jammer  off.  Otherwise  you 
will  be  prompted  to  enter  the  freouency  code  and  sector. 
The  interpretation  of  the  power  and  frecuency  codes  is 
given  in  TAELE  1.* 

Note:  The  defensive  mode  display  will  be  presented  for 
each  refresh  cycle  until  the  BCNPING  MODE  box  is  selected. 

Four  items  require  only  the  cursor/space  bar  pick. 
These  are  the  C  button  to  deploy  a  chaff  pod,  the  F  button 
to  deploy  an  infra-red  flare,  the  ABORT  MISSSION  box  which 
maneuvers  the  aircraft  to  its  preset  abort  profile,  and  the 
RESUME  PREPLANED  FLIGHT  PATH*  box,  which  manuevers  the 
aircraft  back  onto  its  preplanned  route.  This  leaves  only 
the  PCMPING  MODE  box  to  explain. 

Selecting  the  POM PING  MODE  box  allows  you  to  deploy 
one  of  your  remaining  weapons.  This  pick  will  cause  the 
visual  display  to  be  updated  and  shown,  and  the  cursor  to 
again  be  presented.  If  a  smaller  circle  is  drawn  on  the 
visual  display,  this  delimits  the  sites  which  can  be  bombed 
from  your  present  position.  If  no  sites  are  within  range, 
MIRAGE  will  tell  you  so,  and  the  cursor  is  again  the  menu 
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the  space  bar.  You  v^ill  now  be  prompted  for  a  weapon. 


Enter  the  key  number  of  the  weapon  you  want  to  use,  or  a 
zero  if  you  would  rather  not  attack,  followed  by  the 
"return"  key  to  enter  your  choice.  The  cursor  will  be 
ready  to  pick  your  next  command. 

Hote;  To  deploy  another  weapon,  you  must  re-select  BOMBING 
MODE  and  proceed  as  above.  You  will  not  be  allowed  to  pick 
a  second  target  with  the  command  cursor. 

Note;  The  offensive  mode  display  will  be  presented  for 
each  refresh  cycle  until  the  ECM  mode  or  MAX  box  is 
selected  . 

By  now  you  may  be  thinking,  with  all  that  going  on 
I'm  bound  to  make  a  mistake.  It's  not  as  bad  as  it  sounds. 
Remember,  you're  in  a  timeout  mode,  so,  with  only  a  few 
exceptions  you  can  recover  from  an  errant  pick.  First,  the 
exceptions:  deploying  chaff,  flares,  and  weapons.  When  the 
hardware  is  launched  it's  gone;  you  can't  call  it  back. 
The  remaining  maneuvers  can  be  undone  simply.  Picking  a 
change  in  direction,  speed,  or  altitude  will  logically 
over-v/rite  a  previously  indicated  change  in  direction, 
speed,  or  altitude  respectively.  You  can  certainly  turn 
left  and  accelerate  simultaneously,  but  you  cannot  climb 
and  descend.  In  other  words,  if  you  enterred  a  "TURN  LEFT 
30  DEGREES",  but  you  meant  right,  go  back  and  pick  "TURN 
RIGHT"  and  enter  "30"  when  prompted  for  degrees.  Only  the 
last  maneuver  of  each  type  (change  in  direction,  speed,  or 
altitude)  will  be  executed.  Maneuvers  in  the  same  direction 
do  not  combine,  either.  Ten  ACCFLERATF  20  KNOTS  are  the 
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same  as  one.  To  cancel  a  maneuver  altogether,  repick  it 
and  enter  zero  for  the  amount.  If  you  have  had  a 
particularly  bad  " timeout",  and  the  menu  or  interactive 
scratch  pad  are  confusing  you,  it  is  possible  to  clear  the 
display  and  see  your  present  status.  This  control 
character  and  the  others  will  be  described  next. 

Six  special  characters  operate  when  in  the 
interactive  mode.  To  refresh  the  screen,  and  only  show  the 
highlighting  boxes  for  the  current  flight  maneuvers,  enter 
a  lower  case  ”r".  To  change  the  timestep,  that  is,  the 
period  of  simulated  time  which  will  elapse  before  the  next 
automatic  redrawing  of  the  screen,  enter  a  lower  case  "t". 
To  change  the  delay  multiplier,  and  alter  the  real  time 
aspect  of  the  simulation,  enter  a  lower  case  "d".  To 
signal  that  your  inputs  are  complete,  and  you  wish  to 
continue  the  simulation,  enter  a  lower  case  "c"  .  To  have  a 
help  message  displayed,  enter  a  lower  case  "h”.  To 
terminate  the  program  altogether,  and  exit  to  the  command 
mode  of  the  computer,  enter  an  upper  case  "T".  Remember, 
these  only  work  when  you  are  in  the  interactive  mode.  To 
get  there  from  the  run  mode,  hold  the  CTRL  key  and  type  a 
”c".  The  control  functions  are  summarized  in  Figure 


below . 
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FIGURE  A-3 
Control  Characters 


NOTE:  Entering  a  control  c  while  the  screen  is  being 
redrawn  will  cause  a  scrambled  display.  It  does  no  harm, 
however.  To  get  a  usable  display  enter  a  lower  case  "r", 
and  continue  with  your  planned  interaction. 

With  your  new  understanding  of  the  displays  as 
described  above  ,  and  the  commands  used  to  interact  with  the 
program,  you're  now  ready  to  run  the  program.  I'lr  sure  you 
will  enjoy  it! 
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